B C D A E F O - Lehrstuhls für Informations- und ...

Experimentelle Evaluierung eines Ansatzes zur semantisch 

entkoppelten Kommunikation in dynamischen, heterogenen 

Netzwerken mittels Publish/Subscribe 

Diplomarbeit 

Universität Rostock 

Fakultät für Informatik und Elektrotechnik 

Institut für Informatik 

Lehrstuhl für Informations- und Kommunikationsdienste 

vorgelegt von: Roland Seuchter 

Erstgutachter: Prof. Dr. Clemens H. Cap 

Zweitgutachter: Prof. Dr. Peter Forbrig 

Betreuer: Henry Ristau 

Abgabedatum: 25.02.2010

Kurzfassung 

In dieser Arbeit wird ASP (Announcement/Subscription/Publication), ein Routingverfahren 

fü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 prüfen, ob ASP in der Praxis als Middleware fü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 ausgewählten, realistischen Szenario sind die Experimente angesiedelt, mit denen 

die Leistungsfähigkeit von ASP geprü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 


1. Einleitung 1 

1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2. Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.3. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2. Grundlagen und Stand der Technik 4 

2.1. Überblick Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.2. Publish/Subscribe in heterogenen Netzen . . . . . . . . . . . . . . . . . . 6 

2.3. Inhaltsbasiertes Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.3.1. Datenmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.3.2. Adressierungsschemata . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.3.3. Sprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.3.4. Weitere Problemstellungen . . . . . . . . . . . . . . . . . . . . . . 8 

2.4. Publish/Process/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.5. Announcement/Subscription/Publication . . . . . . . . . . . . . . . . . . 11 

2.5.1. Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.5.3. Anwendungsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.5.4. Netzwerkabstraktionsschicht . . . . . . . . . . . . . . . . . . . . . . 15 

2.5.5. Übertragungskategorien . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.6. Andere Publish-Subscribe-Middleware . . . . . . . . . . . . . . . . . . . . 15 

2.7. Routingmetriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

2.7.1. Hop Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.7.2. ETX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.7.3. ETT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.7.4. WCETT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.7.5. MIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

2.8. Netzwerktechnologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

2.8.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

2.8.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2.8.3. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2.8.4. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3. Konzept 26 

3.1. Anwendungsszenarien für PPS . . . . . . . . . . . . . . . . . . . . . . . . 26 

ii


3.2. Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.2.1. Ziele von ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.2.2. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

3.2.3. Variationsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . 30 

3.3. Abbildung auf ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

3.3.1. Anwendungstypen und Übertragungskategorien . . . . . . . . . . . 32 

3.3.2. Plattformen und Netzwerktechnologien . . . . . . . . . . . . . . . . 33 

3.3.3. Anwendungsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.3.4. Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

3.3.5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

3.4. Metrik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

3.4.1. Datentransport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

3.4.2. Datenverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

3.4.3. Metrik für ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

4. Implementierung 44 

4.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

4.2. Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

4.2.1. Rekorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

4.2.2. Speicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

4.2.3. Konverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

4.2.4. Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4.2.5. Weitere Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4.3. Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4.3.1. Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

4.3.2. Priorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.3.3. Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.4. Protokollierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

4.5. NAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

4.5.1. Priorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

4.5.2. Ethernet und WLAN via UDP . . . . . . . . . . . . . . . . . . . . 49 

4.5.3. Bluetooth via OBEX . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

4.6. Nachrichtenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

4.7. Metrik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

5. Experimenteller Ansatz 53 

5.1. Experimente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

5.2. Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

5.2.1. Hardwareumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

5.2.2. Softwareumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

5.2.3. Beispielaufbau und -ablauf . . . . . . . . . . . . . . . . . . . . . . 56 

6. Auswertung 59 

6.1. Heterogenität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

iii


6.2. Räumliche Entkopplung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

6.3. Nachbarschaftsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

6.4. Verwaltungsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

6.5. Zeitliche Entkopplung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

6.6. Alternative Übertragungswege . . . . . . . . . . . . . . . . . . . . . . . . . 66 

6.7. Gestörte Übertragungswege . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

6.8. Alternative Übertragungstechniken . . . . . . . . . . . . . . . . . . . . . . 70 

6.9. Alternative Prozessoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 

7. Schlussbetrachtungen 74 

7.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

7.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

A. Nachrichtenformat 76 

B. Versuche 77 

B.1. Namensschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 

B.2. Übersicht der Experimente . . . . . . . . . . . . . . . . . . . . . . . . . . 77 

B.3. Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

B.4. Hard- und Softwarespezifikationen . . . . . . . . . . . . . . . . . . . . . . 83 

B.5. Ausgewählte Diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

Literaturverzeichnis 88 

iv

Abbildungsverzeichnis 

Abbildungsverzeichnis 

2.1. Komponenten eines PPS-Knotens . . . . . . . . . . . . . . . . . . . . . . . 11 

2.2. Prozessor versendet Abonnements . . . . . . . . . . . . . . . . . . . . . . 12 

2.3. Verbindungsgewichtung durch ETX . . . . . . . . . . . . . . . . . . . . . . 19 

2.4. Beispiel Inter-Flow-Interferenz . . . . . . . . . . . . . . . . . . . . . . . . 20 

3.1. Szenarioskizze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

3.2. Variationsmöglichkeiten im Szenario . . . . . . . . . . . . . . . . . . . . . 30 

3.3. Schnittstellen zwischen Anwendungen und Broker . . . . . . . . . . . . . . 35 

3.4. Nachrichtenverlust nach Routenänderungen . . . . . . . . . . . . . . . . . 38 

3.5. Definition von tproc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

5.1. Logische Trennung eines IP-Netzwerks in Subnetze . . . . . . . . . . . . . 54 

6.1. Verwaltungsaufwand in Experiment 2, Reihe 2 . . . . . . . . . . . . . . . 65 

6.2. Vergleich der Downloadzeiten . . . . . . . . . . . . . . . . . . . . . . . . . 66 

6.3. Beispiel zeitlicher Ablauf der Ausbreitung von Ankündigungen . . . . . . 69 

6.4. Störungen durch Bluetooth Inquiry Scans . . . . . . . . . . . . . . . . . . 71 

B.1. Legende der Versuchsskizzen . . . . . . . . . . . . . . . . . . . . . . . . . 79 

B.2. Versuchsaufbau Experiment 1 . . . . . . . . . . . . . . . . . . . . . . . . . 80 




B.6. Kosten der Ankündigungen in X1v1R1@1M . . . . . . . . . . . . . . . . . 85 

B.7. Kosten der Ankündigungen in X1v1R1@11M . . . . . . . . . . . . . . . . 85 

B.8. Kosten der Ankündigungen in X1v1R1@54M . . . . . . . . . . . . . . . . 86 

B.9. Kosten der Ankündigungen in X1v1R1@auto . . . . . . . . . . . . . . . . 86 

B.10.Kosten der Ankündigungen in X1v1R2@dc80a . . . . . . . . . . . . . . . . 87 

B.11.Kosten der Ankündigungen in X1v1R2@dc100 . . . . . . . . . . . . . . . . 87 

v

Tabellenverzeichnis 

Tabellenverzeichnis 

2.1. Publish-Subscribe-Beispielnachricht . . . . . . . . . . . . . . . . . . . . . . 8 

2.2. ASP-Nachrichtentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.3. Übertragungskategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.4. Vergleich der Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

3.1. Rollenverteilung in den Beispielszenarien . . . . . . . . . . . . . . . . . . . 27 

3.2. Variationsmöglichkeiten der Vernetzung . . . . . . . . . . . . . . . . . . . 31 

3.3. Variationsmöglichkeiten der Rollen und Plattformen . . . . . . . . . . . . 31 

5.1. Kurzü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 Ankü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. Durchgeführte Experimente . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

B.2. Softwareausstattung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

B.3. Hardwareausstattung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

B.4. Netzwerkperipherie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

vi

1. Einleitung 

1. Einleitung 

1.1. Motivation 

Intelligente Umgebungen sollen Menschen in ihren Arbeits- oder Wohnumgebungen 

bei ihren Tätigkeiten unterstützen und sich an die Bedürfnisse ihrer Nutzer anpassen. 

Dazu werden Räume mit Sensoren ausgestattet, die der Umgebung helfen, die Nutzer 

und ihren Kontext wahrzunehmen. Aktoren versetzen die Umgebung in die Lage, 

sich aktiv und selbstständig an die Situation anzupassen. Ein Beispiel sind ferngesteuerte 

Rollläden oder Zimmerlampen, die von einem Beleuchtungssensor gesteuert 

werden, um eine gleichmäßige Beleuchtung zu gewährleisten. Die Flexibilität und Anpassungsfähigkeit 

intelligenter Umgebungen wächst sprunghaft, wenn neben einfachen 

Sensoren und Aktoren weitere Gerä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 Geräte miteinander 

kommunizieren und kooperieren. Bei Sensoren, Aktoren und weiteren Geräten handelt 

es sich aber um völlig unterschiedliche Geräte. Sie unterscheiden sich in ihrer Anzahl, in 

der Rechen- und Speicherkapazität, in der Art und Leistungsfähigkeit der verfügbaren 

Kommunikationsschnittstellen und in der Qualität der Stromversorgung. Ein Beleuchtungssensor 

mit ZigBee-Schnittstelle [Lü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 gegenüberliegenden Enden eines breiten Spektrums. Diese 

heterogene Vielfalt ist charakteristisch für intelligente Umgebungen. 

Ein weiterer interessanter Aspekt intelligenter Umgebungen ist Mobilitä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 Geräte, die fest installiert sind, sondern auch Geräte, 

die mobil sind und die vom Nutzer in immer andere Umgebungen eingebracht werden. Im 

Beispiel ist es wünschenswert, wenn sich das Telefon für die Dauer des Films selbstständig 

in einen leisen Modus versetzt. Verlässt der Benutzer den Raum oder beendet er die 

Aufzeichnung, kehrt das Telefon wieder in seinen ursprünglichen Betriebsmodus zurück. 

Dazu muss es mit den anderen Geräten in der Umgebung kommunizieren. Kabellose 

Verbindungstechniken eignen sich dafür besonders. 

Die folgende Liste enthält zusätzliche charakteristische Eigenschaften für das Umfeld der 

heterogenen Netze in intelligenten Umgebungen: 

1

1. Einleitung 

• paralleler Einsatz von Funkschnittstellen und Kabelverbindungen mit stark unterschiedlicher 

Reichweite, Bandbreite und Verfügbarkeit 

• hohe Anzahl der Geräte 

• unterschiedliche Hardware- und Programmierarchitekturen und damit verbunden 

unterschiedliche Leistungsfähigkeit der Geräte 

Das hat eine Reihe von Konsequenzen für das Netzwerk. Wegen der Vielzahl der Geräte 

herrscht ein tendentiell hoher Kommunikationsbedarf. Arbeitet die Infrastruktur in dieser 

Situation nicht effizient, kann der Bedarf nicht gedeckt werden. 

Dass es mobile Geräte und Geräte mit begrenzter Energieversorgung gibt, führt dazu, 

dass sich die Topologie des Netzes häufig ändert. Einzelne tragbare Geräte werden 

bewegt und die Betriebszustände anderer Geräte ändern sich kurzfristig: An der einen 

Stelle kommt ein mobiles Gerät hinzu, wä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 beträchtlichen Störungen 

ausgesetzt sein und die Verbindungsqualität kann schwanken. Auch dies hat 

Änderungen in der Topologie zur Folge. Weiter kann eine festinstallierte, kabelgebundene 

Infrastruktur vorhanden sein, die im Allgemeinen eine höhere Bandbreite aufweist 

und zuverlässiger ist als kabellose Netze, weshalb sie in die Kommunikationsvorgänge 

einzubeziehen ist. 

Nicht zuletzt führt die Vielfalt der Netzwerkschnittstellen der Geräte dazu, dass nur wenige 

Geräte unmittelbar miteinander kommunizieren können. Ein einheitlicher Adressraum 

existiert nicht. Die Kommunikation muss also koordiniert werden und kooperativ 

sein. Einzelne Geräte mü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 leistungsfähiges und flexibles Kommunikationskonzept zu entwerfen, dass die Geräte 

miteinander verbindet. 

1.2. Zielstellung 

Mit Announcement/Subscription/Publication (ASP) existiert ein neuartiges Konzept, 

das die Kommunikation in heterogenen Netzwerken ermö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 überführt. Das entwickelte System ist die Grundlage fü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 geprüft, die sich wie folgt zusammenfassen lassen: 

1. Das System funktioniert in einem heterogenen Umfeld. 

2. Die Kommunikation ist räumlich entkoppelt und 

3. erfolgt auf Grundlage von Nachbarschaftsbeziehungen. 

4. Das System arbeitet mit einem niedrigen Verwaltungsaufwand. 

5. Die zeitliche Entkopplung der Kommunikation ist gewährleistet. 

6. Unter den alternativen Übertragungswegen wird ein effizienter gewählt. 

7. Gestörte Übertragungswege werden vermieden und 

8. unterschiedliche Übertragungstechnologien können genutzt werden. 

9. Für die Datenverarbeitung werden die leistungsfähigsten der verfügbaren Geräte 

eingebunden. 

Ob ASP die gesteckten Erwartungen erfüllen kann, ergibt die Auswertung der praktischen 

Versuche. Es wird geklärt, wie effizient das implementierte System diese Ziele 

erreicht und an welchen Stellen das Konzept gegebenenfalls verbessert oder konkretisiert 

werden muss. 

1.3. Ü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 weiterführenden System 

Announcement/Subscription/Publication (ASP). ASP ist der Untersuchungsgegenstand 

dieser Arbeit. 

Kapitel 3 erlä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 künftigen Middleware beschrieben. 

Die Besonderheiten der Implementierung beschreibt Kapitel 4. Die Merkmale der Implementierung, 

die für das Verständnis des Ablaufs der Experimente und die spätere 

Auswertung der Versuche von entscheidender Bedeutung sind, stehen dabei im Mittelpunkt. 

Die Anforderungen an die Experimente und das Vorgehen bei den Versuchen enthält 

Kapitel 5. Kapitel 6 diskutiert die durchgefü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 zukünftige Forschungsthemen 

gibt Kapitel 7. 

3

2. Grundlagen und Stand der Technik 


In Abschnitt 1.1 wurden die Merkmale intelligenter Umgebungen dargestellt. Damit die 

Kommunikation in einem solchen Umfeld gewährleistet werden kann, wird eine geeignete 

Infrastruktur benö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 räumlich eng gekoppelt. Client und Server 

mü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 erfüllt. 

Warteschlangensysteme entkoppeln die Kommunikation rä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 

zunächst die Grundlagen von Publish/Subscribe erläutert. Anschließend werden 

schrittweise die Konzepte von Publish/Process/Subscribe (PPS) und Announcement/ 

Subscription/Publication (ASP) eingeführt. PPS ergänzt Publish/Subscribe um Mechanismen 

zur flexiblen Datenverarbeitung und unterstützt auf diese Weise die Kooperation 

von Geräten in intelligenten Umgebungen. Auf PSP aufbauend, ist ASP ein Routingalgorithmus 

fü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. Für ASP wurde bislang keine Metrik festgelegt. Für die praktische 

Umsetzung wird sie jedoch benötigt. Abschnitt 2.7 behandelt existierende Metriken. Sie 

dienen später als Grundlage der Metrik für ASP. 

Die praktische Umsetzung des entwickelten Systems greift auf eine Reihe verbreiteter 

Netzwerktechnologien zurück. Das Kapitel schließt aus diesem Grund mit den wichtigsten 

Eckpunkten der eingesetzten Netzwerktechnologien. 

4


2.1. Überblick Publish/Subscribe 

Publish/Subscribe ist ein Kommunikationsparadigma [EFGK03], das unter anderem der 

Interaktion von Komponenten in komplexen verteilten Systemen besser gerecht werden 

möchte als andere Ansätze, zu denen das Client-Server-Modell, Remote Procedure Calls 1 

(RPC) und Warteschlangensysteme (bzw. nachrichten-orientierte Middleware, MOM) 

gehören. Einen Überblick dieser Techniken bietet [TS08], sodass ihre Hintergründe hier 

nicht weiter Gegenstand sind. Stattdessen veranschaulicht eine detaillierte Betrachtung 

der Komponenten und der Funktionsweise von Publish/Subscribe dessen Potenzial und 

unterstreicht die Vorzüge der zentralen Eigenschaften von Publish/Subscribe. 

An der Kommunikation mittels Publish/Subscribe sind stets drei Parteien beteiligt: Subscriber, 

Broker und Publisher 2 . 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. Mö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 

überprü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 räumlich entkoppelt (anonym). 

2. Je ein Publisher kann mit nur einer Operation Nachrichten an beliebig viele Subscriber 

übertragen (Multicast). 

Versendet der Publisher eine Nachricht, adressiert er die Empfänger nicht direkt. Die 

Verbreitung der Information wird dem Broker überlassen. In der Folge müssen sich die 

Kommunikationspartner nicht kennen. Die Kommunikation gilt als räumlich entkoppelt 

[EFGK03]. Der zweite Punkt besagt, dass der Broker jede eintreffende Nachricht an 

mehrere Empfänger weiterleiten kann, falls sie Interesse daran haben. Unabhängig davon 

können in einem Publish-Subscribe-System mehrere Publisher existieren und aktiv 

Nachrichten versenden. 

Neben der rä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 Empfänger 

einer Nachricht nicht zum gleichen Zeitpunkt aktiv sein müssen. So kann ein Publisher 

eine Nachricht versenden, während der Empfänger dieser Nachricht inaktiv ist, oder 

falls die Verbindung auf Sende- oder Empfangsseite unterbrochen ist. Die Entkopplung 

1 Vereinfachend soll dies auch Remote Method Invocation (RMI) umfassen. 

2 Die Bezeichnung ist uneinheitlich. In einigen Veröffentlichungen heißt es Produzent und Konsument 

statt Publisher bzw. Subscriber; anstelle von Nachrichten wird häufiger von Ereignissen gesprochen 

[CRW00, EFGK03, MC02] u.a. 

5


der Synchronisation bezieht sich auf das Blockieren der Kommunikationsvorgänge. Bei 

Publish/Subscribe mü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) gegenüber, stellt man fest, dass das Publish-Subscribe-Verfahren 

gut für den Einsatz in intelligenten Umgebungen geeignet ist. Die räumliche Entkopplung 

und die Multicast-Semantik helfen, viele Geräte zu verbinden. So müssen die Kommunikationspartner 

nicht aufwändig im Vorfeld einer Kommunikation ermittelt werden und 

während des eigentlichen Kommunikationsvorgangs einzeln angesprochen werden. Die 

veränderliche Topologie, hervorgerufen durch Geräte in unterschiedlichen Betriebszuständen, 

kann durch die zeitliche Entkopplung kompensiert werden, denn sie erlaubt die 

Kommunikation auch dann, wenn einer der beteiligten Endpunkte inaktiv ist. Ähnliches 

gilt für die Entkopplung der Synchronisation. Insbesondere erlaubt sie Applikationen 

auf leistungsschwachen Geräten mit begrenzter Stromversorgung Nachrichten zu verschicken 

oder zu empfangen, ohne unter hohem Zeitaufwand auf andere Geräte warten 

zu mü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 übertragen werden soll. Daneben sind vordefinierte Multicastgruppen oder Flooding 

weitere Mö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 für 

inhaltsbasiertes Routing, denn die Ausdrucksfähigkeit des Mechanismus, mit dem Interesse 

beschrieben werden kann, beeinflusst unmittelbar die Flexibilität des gesamten 

Systems [CJ02]. Die folgenden Abschnitte geben einen Ü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 können. 

Ein weit verbreitetes Modell ist das bei SIENA [CRW00] verwendete, das eine Nachricht 

als eine typenlose Menge typisierter Attribute definiert 3 . 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 Veröffentlichungen dominieren. 

Sivaharan et al. nennen zusätzlich Zeichenketten, Tupel, XML-Dokumente und 

Objekte als Datenmodell [SBC05]. 

2.3.2. Adressierungsschemata 

Die Adressierung von Empfängern in Publish-Subscribe-Systemen kann auf unterschiedliche 

Art und Weise erfolgen. Die drei geläufigsten Ansätze arbeiten entweder 

• kanalbasiert, 

• themenbasiert oder 

• inhaltsbasiert. 

Kanalbasierte Ansätze berücksichtigen den Inhalt von Nachrichten nicht. Stattdessen 

werden Kommunikationskanäle über Namen identifiziert [CRW00]. Ein Subscriber 

abonniert den Kanal und empfängt somit sämtliche Nachrichten, die über den gewählten 

Kanal veröffentlicht werden. In der Implementierung lässt sich dieser Ansatz unmittelbar 

auf existierende Architekturen wie IP-Multicast abbilden. In Tabelle 2.1 ist ein Beispiel 

für eine Nachricht gegeben. In einem kanalbasierten Publish-Subscribe-System könnte 

sie z.B. in dem Kanal ” Börsennachrichten“ veröffentlicht werden. Es steht dem Publisher 

frei, welche Nachrichten er in welchem Kanal veröffentlicht. 

Der Mechanismus themenbasierter Adressierung ist ausdrucksstä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 gewünschte Thema mit dem einer Nachricht überein, 

wird die Nachricht an den interessierten Subscriber ausgeliefert. So könnte das Beispiel 

(Tab. 2.1) das Thema ” Kursä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 erfüllt sind, d.h. 

mit dem Interesse des Subscribers ü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 Übereinstimmungen 

(n aus m ; n < m) zulässt. Zusammenfassend lässt sich sagen, dass die kanalbasierte 

und insbesondere die themenbasierte Adressierung Spezialfälle der inhaltsbasierten Verfahren 

sind [HGM04,CRW00]. Das Beispiel aus Tabelle 2.1 würde die folgende komplexe 

Bedingung erfüllen: 

Unternehmen = ’Friendface’ UND Preis > 21,60 UND 

(Handelsplatz = ’Hannover’ ODER Handelsplatz = ’Stuttgart’) 

Neben den genannten Ansätzen schlagen Eugster et al. ein typbasiertes Verfahren vor, 

welches eine engere Integration von Middleware und Sprache (siehe Abschnitt 2.3.3) 

sowie Typsicherheit ermöglichen soll [EFGK03]. 

2.3.3. Sprachen 

Attribut Wert 

Unternehmen Friendface 

Wertpapier AKTIEFF 

Datum 2009-07-27 

Uhrzeit 14:06 CEST 

Preis 21,64 e 

Handelsplatz Hannover 

Tabelle 2.1.: Eine Beispielnachricht in einem Publish-Subscribe-System. 

Die Ausdrucksfähigkeit eines inhaltsbasierten Publish-Subscribe-Systems hängt von der 

Sprache ab, die genutzt wird, um Interesse – d.h. Abonnements – zu beschreiben. Gängig 

ist die Formulierung als Zeichenkette wobei neben proprietären Sprachen auch SQL oder 

XPath zur Anwendung kommen können [HBS + 02, TRP + 04, EFGK03]. Letzteres ist die 

naheliegende Wahl, wenn Nachrichten in XML kodiert werden. Allgemein sind boolesche 

Ausdrücke vorherrschend. Sie verknüpfen Vergleiche von Attributwerten und Konstanten 

miteinander. Unterschiedliche Vergleichsoperatoren wie =,�=, 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. 

Häufig finden die Ergebnisse Eingang in Routingalgorithmen oder Prototypen. Eines der 

Probleme ist die effiziente Auswertung von Prädikaten, d.h. der Vergleich von Nachrichten 

mit den Interessen der Kommunikationspartner. So wurden Überdeckungsrelationen 

vorgeschlagen, um die Anzahl und Komplexität von Prädikaten zu reduzieren [CRW04]. 

8


Suchbäume sollen die Zahl der Vergleiche auf das für das Weiterleiten von Nachrichten 

nötige Minimum reduzieren [BCM + 99]. 

Über das Wann und Wo der Auswertung von Prädikaten gibt es unterschiedliche Meinungen. 

Das System Kyra [CS04] unterteilt den Raum möglicher Nachrichten und strukturiert 

zusätzlich das Netzwerk der Broker in Cliquen, die in Bäumen organisiert sind, 

um die Vergleiche auf nahegelegenen und (pro Nachricht) weniger Knoten durchführen 

zu müssen. 

Vor dem Hintergrund der Multicast-Eigenschaft von Publish/Subscribe muss man das 

Argument aus [CRW00] sehen, wonach Prädikate möglichst früh, d.h. wenige Stationen 

vom Publisher entfernt auszuwerten sind, Verzweigungen, d.h. Kopien von Nachrichten, 

möglichst spät, also nahe an den Subscribern durchgeführt werden sollen. Beides soll 

die Belastung des Netzwerks minimieren. Konsequenterweise sollten Nachrichten für die 

momentan kein Interesse besteht, überhaupt nicht versendet werden. Diese Optimierung 

ist unter dem Begriff source quenching bereits seit längerem bekannt [SA97]. 

Die Anonymität der Kommunikationspartner und das Multicasting in inhaltsbasierten 

Publish-Subscribe-Systemen erschweren die verlustfreie Ende-zu-Ende-Übermittlung 

von Nachrichten, was in vielen Anwendungen eine wichtige Anforderung an die Dienstgüte 

ist. Mit Gryphon wurde eine komplexe Lösung vorgestellt, die auf Zeitschlitzen 

basiert [BSB + 02] und die Nachrichtenübermittlung absichert. 

Mobile Geräte und insbesondere MANETs 4 stellen besondere Anforderungen. Huang und 

Garcia-Molina beschreiben in [HGM04] Szenarien wie inhaltsbasiertes Publish-Subscribe 

für mobile und Ad-Hoc-Umgebungen erweitert werden kann. Sie untersuchen den Einsatz 

von zentralen, verteilten und replizierten Brokern. Zusätzlich untersuchen sie weitere 

allgemeine Fragen des mobilen Publish/Subscribe. 

Mit zwei unterschiedlichen Vorstellungen von Mobilität beschäftigt sich [FGKZ03]. Fiege 

et al. unterscheiden die transparente Mobilität von Anwendungen, aber auch Mobilität 

und Ortsbezug als Anwendungskontext. In ihrem Ansatz setzen sie auf Stellvertreter von 

Subscribern, die Nachrichten empfangen, wä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 VANETs 5 

und erweitern Publish/Subscribe für ihre Beispielanwendungen um räumliche Nähe als 

weitere Filterdimension. 

2.4. Publish/Process/Subscribe 

Um die volle Leistungsfähigkeit einer intelligenten Umgebung auszuschöpfen, müssen 

alle vorhandenen Geräte miteinander kommunizieren. Wie bereits erläutert wurde (siehe 

S. 1), sind intelligente Umgebungen sehr heterogen. Ziel des in [Ris08] vorgestellten 

4 Mobile ad hoc networks; siehe [Per01]. 

5 Vehicular ad hoc networks; siehe [MSJ09]. 

9


Publish/Process/Subscribe (PPS) ist es, den Geräten zu ermöglichen, unabhängig von 

ihrer Kommunikationstechnologie Daten auszutauschen. Existierende Ansätze sind ungenügend 

und müssen von zentralen Komponenten und dem Bedarf manueller Konfiguration 

befreit werden [Ris08]. Um maximale Flexibilität zu erreichen, setzt das Konzept 

von PPS auf Publish/Subscribe auf (siehe Abschnitte 2.1 und 2.2). Dabei macht es 

sich dessen Vorzüge der räumlichen und zeitlichen Entkoppelung zunutze. Ergänzt wird 

die Architektur aus Publisher, Subscriber und Broker um Prozesse, die Daten verarbeiten 

können (Prozessoren). Diese Prozesse können (Sensor-)Daten auswerten und Geräte 

steuern oder sie unterstützen andere Gerä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 für jeden Knoten eine bestimmte Struktur aus unterschiedlichen 

Komponenten vor (siehe Grafik 2.1). Im heterogenen Netz verfügt jeder (physische) 

Knoten über einen eigenen Broker (lokaler Broker), der die Kommunikation mit benachbarten 

Knoten bzw. deren Brokern ü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 über eine definierte Schittstelle 

verbunden. Die Existenz von Brokern auf jedem Knoten wird damit begründet, dass auf 

diesem Wege lokales Wissen über den Knoten und seine unmittelbaren Nachbarn für den 

Betrieb genügt. Eine globale Sicht und damit die Kenntnis aller Knoten im Netzwerk 

ist nicht erforderlich. Wegen der Heterogenität der Umgebung wäre sie unzweckmäßig. 

Fü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. 

Häufige Topologieänderungen wie sie im Einsatzumfeld von PPS zu erwarten sind, 

treiben zudem die Kosten für das Vorhalten einer konsistenten und aktuellen Sicht auf 

das gesamte Netz in die Höhe. Informationen über die Topologie müssten nach jeder 

Änderung an jeden Knoten im Netz verteilt werden, was das Netzwerk belasten würde. 

Eine weitere Komponente ist der sog. Network Abstraction Layer (NAL), die Netzwerkabstraktionsschicht. 

Sie verbirgt die Eigenheiten einer konkreten Kommunikationstechnik 

vor den darüberliegenden Schichten, also insbesondere vor dem Broker. 

Die Interaktion der Broker und Anwendungen untereinander ist ein Routingproblem 

[Ris08]. Nachrichten mü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 können mehrere Wege von der Quelle zur 

Senke existieren. Die Komplexität wird dabei durch die Einbeziehung der Prozessoren 

erhöht. Um ein Datum d nach d ′ abzubilden, können unterschiedliche Verknüpfungen 

von Funktionen existieren, die sich in der Reihenfolge und Anzahl der Einzeloperationen 

und damit den beteiligten Prozessoren unterscheiden. Es müssen also Wege durch ein 

Netzwerk gefunden werden, die möglichst kostengünstig sind. In [Ris08] werden drei 

Strategien für das Routing vorgestellt, von denen ein auf Flooding basierender Ansatz 

10


Nachbarn 

Quelle 

Quelle 

Prozessor 

Prozessor 

Anwendungss. 

Broker 

NAL 

Senke 

Senke 

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 

über Nachbarknoten. Abbildung nach [Ris08]. 

weiter verfolgt wird und in das Konzept Announcement/Subscription/Publication (ASP) 

mündet. Einer der beiden weiteren Vorschlä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 mö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 ergänzt einen Routingalgorithmus [Ris09a]. 

2.5.1. Interaktion 

Die Interaktion zwischen den Brokern und den restlichen Komponenten des ASP-Systems 

läuft in drei Phasen ab: Ankündigung, Abonnement und Veröffentlichung. Jede 

dieser Phasen wird auf einen separaten Nachrichtentyp abgebildet. Sämtliche Nachrichten 

tragen Identifikationsnummern. Sie werden fortan als ASP ID oder verkürzend als 

ID bezeichnet. Trägt eine Ankündigung zum Beispiel die ID 7e44a5e4, so tragen alle 

nachfolgenden Abonnements und Veröffentlichungen, die auf die Ankündigung bezug 

nehmen dieselbe ID. Dies entspricht der themenbasierten Adressierung (siehe Seite 7). 

Mit Ankündigungen (Announcement) signalisieren Quellen, dass sie Daten im Netz 

zur Verfügung stellen. Ankündigungen werden grundsätzlich an alle Broker im Netzwerk 

11


verteilt. Broker erhalten auf diese Weise eine Übersicht über die verfügbaren Datenquellen 

und lernen den Nachbarn kennen, über den die Nachrichten bezogen werden 

können. Eine Ankündigung kann eine Beschreibung der Daten enthalten, die die Quelle 

in Zukunft unter der gegebenen ID veröffentlichen wird. Handelt es sich bei einer 

Quelle beispielsweise um eine Webcam, die regelmäßig Aufnahmen macht, kann eine 

Ankündigung Informationen wie den Standort der Kamera, Bildmaße usw. enthalten. 

ASP legt weder die Form noch den Inhalt von Ankündigungen fest. Die Erzeugung 

und Interpretation einer Ankündigung ist den Anwendungen (Quelle, Prozessor, Senke) 

überlassen. Erzeugt eine Quelle Nachrichten von geringem Umfang oder werden sie nur 

selten versendet, kann eine Ankündigung statt einer Beschreibung das komplette Datum 

enthalten. Ein Temperatursensor kann auf diese Weise den jüngsten Messwert mit einer 

Ankündigung verbreiten. Neben Quellen können auch Prozessoren den Versand von 

Ankündigungen auslösen. Dies geschieht als Reaktion auf Ankündigungen von anderen 

Quellen oder Prozessoren, wenn ein Prozessor aus den bisher empfangenen Ankündigungen 

A1, A2 usw. beziehungsweise den entsprechenden Veröffentlichungen P1, P2 usw. 

eine neue Ankündigung A ′ (bzw. P ′ ) erzeugen kann. 

Ein Abonnement (Subscription) wird als Reaktion auf eine Ankündigung verschickt. 

Bevor eine Senke ein Abonnement auslösen kann, muss sie eine Ankündigung empfangen 

haben. Wird eine Ankündigung eines Prozessors abonniert, abonniert dieser alle Ankündigungen, 

die nötig sind, um die gewünschten Veröffentlichungen erzeugen zu können 

(siehe Grafik 2.2). 

S’ 

Proz. 

Broker 

Abbildung 2.2.: Ein Prozessor erhält ein Abonnement S ′ und versendet daraufhin Abonnements 

für S1, S2, S3. 

Neben Abonnements existieren Kündigungen. Sind ein Prozessor oder eine Senke nicht 

länger an den Daten einer Quelle interessiert, versendet der zuständige Broker eine 

Kündigung, die dieselbe ID wie die Ankündigung trägt. Spätere Veröffentlichungen mit 

dieser ID werden dem Prozessor oder der Senke nicht zugestellt. 

Die von Quellen angebotenen Daten werden in Form von Veröffentlichungen (Publication) 

verbreitet. Jede Veröffentlichung trägt die zur jeweiligen Ankündigung und 

dem Abonnement gehörende ID. Liegt einem Broker kein Abonnement zu einer ID vor, 

versendet der Broker die von den lokalen Anwendungen erzeugten Veröffentlichungen 

nicht. 

S1 

S2 

S3 

12


2.5.2. Routing 

ASP sieht einen Routingalgorithmus vor, der lediglich voraussetzt, dass Knoten ihre 

unmittelbaren Nachbarn kennen, mit denen sie direkt kommunizieren können. 

Ankündigungen werden wie bereits erwähnt, an alle Broker im Netz verteilt. Um dies zu 

erreichen, werden Ankündigungen im Netzwerk geflutet. Eine neue Nachricht (Ankündigung) 

wird an alle benachbarten Broker und lokalen Prozessoren und Senken verteilt. 

Empfängt ein Broker bi eine Ankündigung von einem Nachbarn, speichert er, von welchem 

Nachbarbroker bj die Ankündigung versendet wurde. Außerdem merkt der Broker 

bi sich die Kosten der Nachricht. Eine Metrik akkumuliert die Kosten der Weiterleitung 

der Ankündigung vom erzeugenden Broker b0 bis zum empfangenden Broker bi. Anschließend 

reicht der Broker die Ankü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, über die die Ankündigung 

weitergeleitet wird, angepasst. Broker speichern die IDs von Ankündigungen, die 

sie bereits weitergeleitet haben. Eine Ankündigung wird von jedem Broker nur einmal 

an seine Nachbarn weitergeleitet. Dadurch ist sichergestellt, dass die Weiterleitung der 

Nachrichten terminiert. 

Erhält eine Senke von ihrem Broker eine Ankündigung und ist sie an zukünftigen Veröffentlichungen, 

wie sie in der Ankündigung beschrieben werden, interessiert, signalisiert 

die Senke dies ihrem Broker. Dieser erzeugt ein Abonnement mit der ID der Ankündigung. 

Kann das Abonnement nicht von einer lokalen Quelle oder Prozessor bedient 

werden, verschickt der Broker die Nachricht an einen seiner Nachbarn. Der Broker wählt 

den Nachbarn, dessen Kosten laut Metrik für die gegebene ID minimal sind. Abonnements 

gelangen schrittweise zum Broker, der die ursprüngliche Ankündigung versandt 

hat. Empfä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 günstigsten Ankündigung weitergeleitet. Stammt die 

günstigste Ankündigung A ′ von einem lokalen Prozessor, wird die Nachricht an diesen 

weitergegeben. Für alle Ankündigungen A1 bis An (n ≥ 1), die der Prozessor verarbeiten 

muss, um A ′ erzeugen zu können, werden Abonnements verschickt. Erreicht ein Abonnement 

die Quelle der Ankündigung, wird die Nachricht nicht weitergeleitet. Der Broker 

merkt sich von welchem Nachbarn das Abonnement gesendet wurde. Kündigungen werden 

auf dieselbe Weise weitergeleitet wie Abonnements. 

Veröffentlicht eine Quelle Daten, erzeugt der Broker eine Veröffentlichung und sendet sie 

an alle Nachbarn, die Teil eines aktiven Pfades für die gegebene ID sind. Beim Empfang 

einer Veröffentlichung reicht ein Broker die Daten an lokale Anwendungen (Prozessor 

oder Senke), falls diese die ID der Veröffentlichung abonniert haben. Danach wird die Veröffentlichung 

an alle Nachbarn weitergeleitet, von denen Abonnements der ID vorliegen. 

Damit die Zahl der von einem Broker gespeicherten aktiven Pfade und weitergeleiteten 

Ankündigungen nicht beliebig zunimmt, wird jede Ankündigung bei ihrer Erzeugung 

mit einer Gültigkeitsdauer versehen. Ist die Gültigkeit einer Ankündigung abgelaufen, 

13


werden alle damit verbundenen aktiven Pfade ungültig. Veröffentlichungen werden dann 

von den Brokern entlang dieser Pfade nicht mehr weitergeleitet. Ein ungültiger Pfad 

und die zugrunde liegende Ankündigung werden von Brokern gestrichen. Quellen und 

Prozessoren bzw. deren Broker verlängern Ankündigungen vor Ablauf ihrer Gültigkeit. 

Um eine eventuell aufgetretene Verdopplung einer Ankündigung von einer Verlängerung 

derselben unterscheiden zu können, tragen Ankündigungen Sequenznummern. 

Ein weiterer Nachrichtentyp wird verwendet, wenn es bei der Weiterleitung von Veröffentlichungen 

entlang eines aktiven Pfades zu Ausfällen von Knoten oder Verbindungen 

kommt. Erkennt ein Broker ein solches Problem wird eine Störungsmeldung ( ” broken 

path“, siehe [Ris09a]) erzeugt. Die Meldung trägt die ID der Ankündigung, die dem 

gestörten aktiven Pfad vorausging und wird nach demselben Verfahren wie Abonnements 

zur Quelle einer Ankündigung weitergeleitet. Dort erzeugt der betreffende Broker 

eine neue Ankü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 Kurzbeschreibung 

Ankündigung Information über die Verfügbarkeit von Daten, 

Routenfindung 

Abonnement Ausdruck von Interesse, Aufbau aktiver Pfade 

Kündigung Abbau aktiver Pfade 

Störungsmeldung Reparatur kaputter, aktiver Pfade 

Veröffentlichung Transport von Daten zwischen Quelle, Prozessor 

und Senke 

Tabelle 2.2.: Eine Ü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 müssen sich Anwendungen zunächst beim lokalen Broker registrieren. 

Dadurch werden der Versand und Empfang von Daten ermöglicht. Für Senken und Prozessoren 

– die einzigen möglichen Empfänger von Nachrichten – ist vorgesehen, dass sie 

bei der Registrierung einen Filter angeben. Ein Filter schränkt die Menge der Ankündigungen, 

die vom Broker an die jeweilige Anwendung weitergereicht werden, ein. So 

erhält die Anwendung nur Ankündigungen, die den Filter passieren. Ohne Filter werden 

alle gültigen Ankündigungen zugestellt, die den Broker erreichen. 

Für die Schnittstelle zwischen Prozessoren und Broker ist vorgesehen, dass ein Prozessor 

Angaben über die Kosten der Datenverarbeitung macht. Der Broker bestimmt daraus 

die Gesamtkosten. 

14


2.5.4. Netzwerkabstraktionsschicht 

Zu den Aufgaben der Netzwerkabstraktionsschicht (NAL) gehört das Erkennen und Verwalten 

von Nachbarknoten. Nachrichten soll der NAL bei der Übertragung zwischen 

Nachbarn vor Verlust schützen. Außerdem sammelt die Schicht Informationen über Verbindungen, 

um die Metrik zu berechnen, die die Weiterleitung von Nachrichten steuert. 

Existiert ein NAL für die darunterliegende Sicherungsschicht ( ” [data] link layer“), 

spielt es keine Rolle, ob das Gerät über Bluetooth-, ZigBee- oder IEEE 802.11b WLAN- 

Schnittstellen verfügt. Dabei muss der NAL nicht notwendigerweise von diesem Niveau 

abstrahieren, sondern kann z.B auch auf UDP/IP aufsetzen. 

2.5.5. Übertragungskategorien 

Die Art der Nachrichten (Veröffentlichungen) und damit der Daten, die in einem ASP- 

Netzwerk verteilt werden, kann von Anwendung zu Anwendung stark variieren. Eine 

Unterteilung aller denkbaren Übertragungen in vier Kategorien wird daher in [Ris09a] 

vorgenommen. Die Einteilung in die Kategorien erfolgt anhand der Nachrichtengröße 

bzw. der Häufigkeit von Veröffentlichungen. Daraus ergeben sich folgende Kategorien: 

Kategorie Nachrichtengröße Häufigkeit 

1 klein Einzelnachrichten 

2 klein Nachrichtenstrom 

3 groß Einzelnachrichten 

4 groß Nachrichtenstrom 

Tabelle 2.3.: Einteilung der Übertragungen in Kategorien nach [Ris09a]. 

Die Einteilung wird vorgenommen um unterschiedliche Optimierungen bei der Verteilung 

der Nachrichten anwenden zu kö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 Veröffentlichungen, sind größer 

als einzelne Nachrichten auf der Sicherungsschicht 6 des Netzwerks sein können. ASP 

sieht daher einen Mechanismus zur Fragmentierung von Veröffentlichungen in mehrere 

Nachrichten vor. 

2.6. Andere Publish-Subscribe-Middleware 

Es gibt Middleware, die Publish/Subscribe in heterogenen Netzen oder intelligenten Umgebungen 

umsetzt. Erwä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 größ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 räumlichen Nähe in die Verbreitung von Nachrichten. 

Die Fähigkeit, die Middleware schnell an andere Umgebungen anzupassen und somit 

schnell zwischen infrastrukturbasiertem und Ad-Hoc-Funk wechseln zu können, sind 

die herausragenden Eigenschaften von GREEN [SBC05]. Der modulare Aufbau und die 

Möglichkeit der Rekonfiguration zur Laufzeit erlauben GREEN die Verwendung themenund 

inhaltsbasierter Publish-Subscribe-Adressierung. Darüber hinaus werden Ereignisse 

im Netz je nach Konfiguration über Multicast-Overlay-Netze oder strukturierte Overlay- 

Netze transportiert. Die Middleware kann bei Bedarf für bestimmte Dienstgütemerkmale 

konfiguriert werden. Als Beispiel nennen die Autoren die Zustellung von Nachrichten innerhalb 

festgelegter zeitlicher Fristen. 

Die Publish-Subscribe-Middleware Rebeca wurde erweitert, um Mobilität von Clients 

(Publisher oder Subscriber) zu ermöglichen [FGKZ03]. Die Autoren unterscheiden dabei 

zwei Formen von Mobilität: Physische und logische Mobilität. Darunter verstehen sie 

Standortänderungen von Clients auf der einen Seite und die Änderung der Position als 

Anwendungskontext auf der anderen Seite. Sie schlagen Verfahren vor, wie beide Arten 

der Mobilität in die bestehende Publish-Subscribe-Middleware integriert werden können. 

Der Umgang mit der physischen Mobilität basiert auf einem virtuellen Subscriber, an 

den Nachrichten ausgeliefert werden, während sich der reale Subscriber (vom Netzwerk 

getrennt) bewegt [ZF03]. Wenn der Subscriber wieder Anschluss an das Netz findet, 

werden zwischenzeitlich veröffentlichte Nachrichten zugestellt. 

Aitenbichler et al. haben mit MundoCore ein umfangreiches Middleware- und Programmier-Framework 

für den Einsatz in intelligenten Umgebungen entwickelt [AKM07]. Es 

bietet kanalbasiertes und inhaltsbasiertes Publish/Subscribe. In der Transportschicht 7 

werden IP, serielle Bluetoothverbindungen und Infrarotverbindungen unterstützt. Die 

modularen Protokollstapel erlauben den Einsatz unterschiedlicher Routingstrategien wie 

hierarchisches Routing und strukturierte Overlay-Netze. MundoCore ist u.a. für die Java- 

Plattformen J2SE 8 und J2ME/CLDC 9 verfügbar und unterstützt damit eine Vielzahl 

von Endgerä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. 

8 

Java 2 Standard Edition. Siehe [Ull07]. 

9 

Java 2 Micro Edition / Connected Limited Device Configuration. Siehe [Sun03]. 

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 (Bogenzüge), so wä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 Bedürfnisse einer bestimmten Netzwerkinfrastruktur 

angepasst sind. Außerdem sind die Berechnungen zur Gewichtung einzelner 

Kanten unterschiedlich aufwändig und erfordern jeweils anderes Wissen ü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 erhöhen. Im folgenden 

werden die Metriken Hop Count, ETX, ETT, WCETT und MIC ü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 trägt die Bezeichnung Hop Count. Der Begriff bezieht sich 

auf die Anzahl der Verbindungen, über die eine Nachricht übertragen werden muss, damit 

sie von einem Knoten zu einem anderen gelangt. Die Zahl ist äquivalent zur Anzahl 

der Kanten, die ein Pfad zwischen zwei unterschiedlichen Knoten enthält. Es ergibt sich 

dhopcount(e) = 1 mit e ∈ E. Die Metrik wird oft verwendet, weil bei ihrer Verwendung das 

Netzwerk dazu tendiert, die Übertragungsverzö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 über die Verbindungsqualität 

in die Gewichtung von Kanten eingehen. Dies ist insbesondere in Funknetzen 

eine Schwäche des Ansatzes. Während die kabelgebundene Übertragung z.B. im 

Ethernet oder entlang von Lichtwellenleitern stabil ist, wird die Übertragung per Funk 

von vielen Faktoren beeinträchtigt. Dazu gehö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 [Lüd07]. So kann es vorkommen, dass Daten 

beim Empfänger nicht empfangen werden oder nicht dekodiert werden können. In solchen 

Fällen muss die Übertragung wiederholt werden. An dieser Stelle setzt die Expected 

Transmission Count Metric (ETX) an [DABM05]. Für jede Verbindung zwischen zwei 

Stationen wird ermittelt, wie oft ein Datenpaket voraussichtlich versendet werden muss, 

17


bis es erfolgreich empfangen werden kann. Dadurch berücksichtigt die Metrik Störungen 

auf dem Übertragungskanal. Ein stark gestö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 Häufigkeit, dass ein versandtes Paket 

beim Empfänger eintrifft (forward) bzw. dass der Absender eine Bestätigung über den 

Erhalt eines Pakets empfängt (reverse). Die konkreten Werte werden über regelmäßig 

ausgesandte Testpakete gemessen. Die Summe der Kosten der einzelnen Verbindungen 

entlang eines Pfades ergeben dessen Kosten. 

In [DABM05] präsentieren die Entwickler des Verfahrens die Ergebnisse einer experimentellen 

Evaluation. ETX erzielt dabei einen höheren Durchsatz als die Hop-Count- 

Metrik. Der Hauptgrund ist, dass ETX es ermöglicht, längere Pfade zu nutzen, die im 

Gegenzug allerdings stabiler sind und damit einen höheren Durchsatz erreichen können. 

Bei Hop Count werden Verbindungen mit einer hohen Reichweite bevorzugt, die aufgrund 

der hohen Entfernung jedoch häufiger höhere Verlustraten aufweisen als Verbindungen 

über kürzere Strecken [DABM05]. Der Einfluss dieses Effektes steigt, wenn man 

berücksichtigt, dass drahtlose Netzwerke nach IEEE 802.11abg mit unterschiedlichen Datenraten 

arbeiten können, aber nur bei den geringsten Datenraten die hö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 über den Knoten C nur mit 11 MBit/s. Die Verbindung über 

Knoten C ist jedoch stabiler: Jede der beiden Kanten hat ein Gewicht von nur 1,1 (ETX- 

Metrik), während die Verbindungen über Knoten B den Wert 1,2 haben, also geringfügig 

unzuverlässiger sind. In einem solchen Fall würde ETX stets den Pfad über Knoten C 

bevorzugen, auch wenn der Pfad über Knoten B einen höheren Durchsatz verspricht. 

ETT bezieht die Bandbreite einer Verbindung ein, und das Gewicht einer Kante berechnet 

sich wie folgt: 

ETT = ETX S 

(2.2) 

B 

S ist die Paketgröße, B reprä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 über die aktuelle Bandbreite 

18


A 

1,2 

B 

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, über die Treiber der Hardware ist sie jedoch nicht 

immer zugä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 Empfä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. fü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 für Funknetzwerke sind, werden von den bisher besprochenen Metriken 

nur unzureichend oder gar nicht berü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 Intra- 

Flow-Interferenz bezeichnet dabei die Stö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. 

Verfügen die Knoten über mehrere Funkadapter, die es ihnen ermöglichen auf unterschiedlichen 

Kanälen oder in unterschiedlichen Bä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-Flow- 

Interferenz durch die Nutzung unterschiedlicher Kanä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 

1,2 

D 

19


A 

E 

B 

C 

F 

Abbildung 2.4.: Inter-Flow-Interferenz: Laufen parallel Übertragungen zwischen A-C-D 

und E-F-G, stören sich die Signale der Knoten C und F. Die Route A- 

B-D wäre die bessere Wahl für den ersten Datenfluss. Grafik angelehnt 

an [YWK05]. 

Interferenzen steigt. Sie bevorzugen jedoch keine Pfade, die eine erhöhte Verlustrate 

durch geeignete Kanalwahl vermeiden. 

Einzelne Kanten können nicht sinnvoll durch WCETT gewichtet werden. Es muss immer 

der gesamte Pfad bewertet werden, wozu die folgende Formel dient [DPZ04]: 

WCETT = (1 − β) · 

n� 

i=1 

D 

G 

ETTi + β · max 

1≤j≤k Xj 

(2.3) 

Die Variable i bezeichnet die Nummer der Kante eines gegebenen Pfades bestehend aus 

n Kanten, auf dem k unterschiedliche Kanäle genutzt werden. Xj ist die Summe der 

zu erwartenden Übertragungsdauer ETT entlang derjenigen Kanten, die auf Kanal j 

funken. Der Faktor β gewichtet die beiden Summanden gegeneinander. Die WCETT- 

Metrik wurde für das Protokoll MR-LQSR 10 umgesetzt und Experimente mit Knoten, 

die durchgängig über zwei Funkadapter (nach 802.11g und 802.11a) verfügten, ergaben 

eine Steigerung des durchschnittlichen Durchsatzes von über 80 % gegenüber ETX 

und über 250 % gegenüber Hop Count [DPZ04]. Während der Messungen war immer 

nur eine Übertragung aktiv. Inter-Flow-Interferenz konnte nicht auftreten. Die Metrik 

berücksichtigt sie auch nicht. 

2.7.5. MIC 

Yang et al. stellen die Metric of Interference and Channel-switching (MIC) vor, die 

die Kanalqualität, Bandbreite, Intra- und Inter-Flow-Interferenz von Verbindungen und 

10 Multi-Radio Link-Quality Source Routing 

20


Netzen berücksichtigt [YWK05]. Für Pfade berechnet sie sich nach der Formel: 

MIC(p) = 

1 

N · min (ETT) 

� 

link l∈p 

IRUl + � 

node i∈p 

CSCi 

(2.4) 

Die beiden Summanden berücksichtigen die unterschiedlichen Eigenschaften von Verbindungen 

in vermaschten Funknetzen. IRUl entspricht hierbei der zu erwartenden Übertragungsdauer 

entlang einer Verbindung l multipliziert mit der Zahl benachbarter Knoten, 

die durch Übertragungen auf l beeinträ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 störenden Stationen sollen 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. 

Die Autoren von MIC argumentieren, dass die Metrik anders als WCETT auch dann 

nicht zu Routing-Schleifen führen kann, wenn auf Source Routing verzichtet wird. Sie 

implementieren ein eigenes Routing-Protokoll (LIBRA) und präsentieren die Ergebnisse 

von Simulationen wonach IRU / LIBRA leistungsfähiger sind als ETT / WCETT. 

Symmetrie 

Kapazität 

Intra-Flow-I. 

Inter-Flow-I. 

Verlustrate 

Metrik 

Hop Count ◦ ◦ ◦ ◦ ◦ 

ETX � � ◦ ◦ ◦ 

ETT � � � ◦ ◦ 

WCETT � � � � ◦ 

MIC � � � � � 

Tabelle 2.4.: Vergleich der Verbindungs- und Pfadeigenschaften, die von den vorgestellten 

Metriken berücksichtigt werden. 

2.8. Netzwerktechnologien 

In diesem Abschnitt werden die für diese Arbeit wichtigsten Aspekte ausgewählter Netzwerktechnologien 

vorgestellt. Auf weiterfü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 lässt sich in Schicht 3 (Netzwerkschicht) des OSI- 

Referenzmodells einordnen [Tan03, Kapitel 1.4]. Die für diese Arbeit relevantesten Punkte 

werden ausgewählt und kurz erläutert. Weitere Details kö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 Binä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 erhält dazu eine Subnetzmaske. Sie hat mit 32 Bit dieselbe 

Länge wie IP-Adressen. Die gesetzten Bits einer Subnetzmaske bestimmen welche 

Bits der IP-Adresse deren Netzwerkanteil ausmachen. Subnetzmasken werden wie IP- 

Adressen notiert, z.B. 255.255.255.0. Zwei Computer im selben physischen Netzwerk, 

die unterschiedliche IP-Adressen haben, kö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 kö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 häufig gemeinsam dargestellt, z.B. 

192.168.5.30/255.255.255.224 [FLYV93]. Eine verkü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 Broadcastadressen 12 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 grundsätzlich nicht geroutet 

und sprechen alle Computer im lokalen Netzwerk an. Die Adresse wird als eingeschränkte 

Broadcastadresse 13 bezeichnet. IP-Broadcastadressen werden soweit wie möglich auf die 

Broadcastadressen der konkreten darunterliegenden Technologie (z.B. Ethernet) abgebildet. 

12 

13 

” directed broadcast address“ [Com00, S. 65 f.] 

” limited broadcast address“ [Com00, S. 66 f.] 

22


2.8.2. UDP 

Das User Datagram Protocol (UDP) ist ein auf IP basierendes Protokoll zur Übertragung 

von Nachrichten zwischen unterschiedlichen Prozessen (auf unterschiedlichen 

Rechnern). Diese Nachrichten werden Datagramme genannt und haben eine definierte 

Länge. UDP sichert die Datenübertragung nicht gegen Verlust ab. Die Integrität der 

Nachrichten wird optional mit Prü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 kö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 Geräte miteinander verbindet [Lüd07]. Besonders 

verbreitet sind WLANs, nach den Standards der Gruppe 802.11 des Konsortiums 

IEEE 14 . Momentan zählen die Standards 802.11, 802.11b, 802.11g, 802.11a und 

das kürzlich verabschiedete 802.11n zu den wichtigsten der Gruppe. Sie werden hier 

verkü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-Band 15 . 

Das Frequenzband darf lizenzfrei für zivile Anwendungen genutzt werden, wobei die maximale 

Sendeleistung begrenzt ist. In demselben Frequenzband arbeiten auch Bluetooth 

und ZigBee [Lüd07]. WLAN nach 802.11bg, Bluetooth und ZigBee beeinträchtigen sich 

wechselseitig. Mikrowellenherde strahlen im oberen Bereich des 2,4-GHz-Bandes Signale 

ab und sind eine weitere Störquelle beim Betrieb von 802.11bg WLANs. 

Das von WLANs genutzte Frequenzband wurde in unterschiedliche Kanäle unterteilt. Die 

Wahl unterschiedlicher Kanäle ist ein Mittel ” um mehrere Funkzellen parallel und voneinander 

unabhängig innerhalb eines Empfangsbereichs betreiben zu können, [...]“ [Rec06, 

S. 102]. Nicht alle Kanäle sind überlappungsfrei. Bei Übertragungen auf zwei unterschiedlichen 

Kanälen kann es zu Interferenzen kommen. In der Praxis wurde beobachtet, dass 

sich bei parallelem Betrieb sogar Geräte beeinträchtigen können, die in unterschiedlichen 

Frequenzbändern (2,4 GHz und 5 GHz) arbeiten [DPZ04, S. 120]. 

WLANs nach 802.11 können in unterschiedlichen Betriebsmodi verwendet werden. Einer 

davon ist der sogenannte Ad-Hoc-Modus, der andere der Infrastrukturmodus. Der Ad- 

Hoc-Modus ist der simpelste Betriebsmodus. Die Funkzellen, die von den Geräten aufgespannt 

werden, werden IBSS (Independent Basic Service Set) genannt. Zwei oder mehr 

Geräte mit Funkadapter können in einem Ad-Hoc-Netzwerk Daten austauschen, wenn 

sich ihre IBSS gegenseitig räumlich überlappen und sie einen gemeinsamen Adressraum 

14 Institute of Electrical and Electronics Engineers, http://www.ieee.org/ 

15 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 Geräten, die das Netzwerk nutzen 

mö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 grundsätzlich erst an einen AP gesendet, der die 

Daten an den Empfänger oder, wenn dieser nicht erreichbar ist, an einen anderen AP 

weiterleitet. Um an dem Infrastrukturnetzwerk teilzunehmen, muss sich ein Gerät mit 

einem AP assoziieren und sich gegebenenfalls authentifizieren. 

WLAN-Geräten stehen für die Datenübertragung unterschiedliche Datenraten zur Verfügung. 

Bei 802.11 sind dies 1 und 2 MBit/s, bei 802.11b zusä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 

höchstmögliche Rate verwendet. Lässt die Übertragungssituation das nicht zu, wird die 

Rate automatisch gesenkt. Üblicherweise werden Broadcasts mit anderen Datenraten 

versendet als Unicasts. Die genauen Verfahren zur Auswahl der Datenrate sind nicht 

spezifiziert. Eine genauere Erklärung kann [Rec06, S. 242 f.] entnommen werden. Bei 

einigen Systemen kann die Datenrate fest gewählt werden. Davon wird bei den später 

beschriebenen Versuchen Gebrauch gemacht. 

2.8.4. Bluetooth 

Bluetooth wurde mit dem Ziel entwickelt, eine kostengünstige und energiesparende Technologie 

für die Verbindung von Computern, Computerperipherie und mobilen Geräten 

über kurze Strecken zu schaffen [Mul01]. Die erste Spezifikation wurde von der Bluetooth 

SIG 16 1999 vorgelegt. 2009 wurden die Versionen 3.0 und 4.0 verö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 Übertragungsmodus können 

Netto-Datenraten zwischen 0,4 MBit/s und 2,2 MBit/s (Bluetooth 2.0 + EDR) erreicht 

werden [Lüd07]. 

Möchten mehrere Bluetooth-Geräte Daten austauschen, bilden sie ein sogenanntes Piconetz, 

das bis zu 8 aktive Geräte umfassen kann. Eines der Geräte im Piconetz übernimmt 

die Rolle des Masters, alle anderen sind Slaves. Der Verbindungsaufbau für die Teilnahme 

am Piconetz läuft in mehreren Stufen ab [Lüd07, S. 242 ff.]. Einer davon ist der Inquiry 

Scan. Bluetooth-Geräte müssen in einem speziellen, sichtbaren Modus sein, damit sie von 

anderen Bluetooth-Geräten im Rahmen eines Inquiry Scans gefunden werden können. Inquiry 

Scans sind zeitaufwä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 Geräten auszutauschen, wie zum Beispiel elektronische Visitenkarten 

oder Klingeltöne. In seinem Funktionsumfang ähnelt es HTTP. Das GOEP (Generic Object 

Exchange Protocol) ist die Grundlage um OBEX über Bluetooth nutzen zu kö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 übertragen. 

25

3. Konzept 

3. Konzept 

In diesem Kapitel werden zunächst einige motivierende Anwendungsszenarien für PPS 

genannt. Sie veranschaulichen die breiten Einsatzmö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 können. 

Den Abschluss des Kapitels bildet die Diskussion der Metrik für ASP. Die in Abschnitt 

2.7 vorgestellten Metriken werden auf ihre Eignung überprüft. Eine der Metriken wird 

so ergänzt, dass sie in einer Implementierung von ASP zum Einsatz kommen kann. 

3.1. Anwendungsszenarien für PPS 

Die Möglichkeit der Kooperation der unterschiedlichsten Geräte einer intelligenten Umgebung 

eröffnet eine ganze Reihe neuer Anwendungsfälle. Vier Szenarien sollen zunächst 

den Bedarf und die breiten Einsatzmöglichkeiten von PPS unterstreichen. 

Bereits in [Ris08] wurde eine Anwendung für eine Büroumgebung vorgestellt. Eine Person 

hat auf ihrem tragbaren Gerät (z.B. ein Smartphone) Dokumente gespeichert, die 

gedruckt werden sollen. An einen Desktop-PC im Büro ist ein Drucker angeschlossen. 

Dieser PC kann das Format, in welchem die Dokumente auf dem tragbaren Gerät gespeichert 

sind, nicht interpretieren. Auf der anderen Seite kennt das Mobilgerät weder 

den Drucker noch hat es einen passenden Treiber. Mit PPS können weitere Prozesse 

oder Geräte aus der intelligenten Umgebung in den Kommunikationsvorgang integriert 

werden, die die Daten konvertieren und auf diese Weise das Ausdrucken ermöglichen. 

Ein ähnliches Szenario ist das eines Beamers, der Urlaubsbilder wiedergeben soll, die 

auf einem Handy gespeichert sind. Auf Grundlage von PPS könnten die Bilder an das 

Gerät, welches mit dem Beamer verbunden ist, übertragen werden und mit Musik aus 

einer weiteren Quelle zu einer Diashow verbunden werden. 

Weitere Einsatzgebiete gibt es an öffentlichen Orten. Auf einem Bahnhof oder Flughafen 

ließen sich die Nachrichtenmeldungen, die prominent über große Monitore angezeigt werden, 

in Echtzeit übersetzen – entsprechende Übersetzungstechnologie vorausgesetzt. So 

könnte ein Geschäftsreisender aus Japan, der kein Russisch spricht, auf dem Moskauer 

Flughafen die Nachrichten verfolgen, die ihm von einem leistungsfähigen Rechner in der 

26

3. Konzept 

intelligenten Umgebung übersetzt werden und dann über das Headset seines Smartphones 

wiedergegeben werden. 

Und auch in der Heimautomatisierung gibt es interessante Anwendungen. Kommunizieren 

sie per PPS, können der intelligente Stromzähler und schaltbare Steckdosen oder 

netzwerkfähige weiße Ware wie Waschmaschine oder Geschirrspüler zusammenarbeiten, 

um den idealen Zeitpunkt für die Inbetriebnahme zu finden. Bei einem viertelstündlich 

neu festgesetzten Strompreis werden die Geräte dann aktiv, wenn der Strompreis mehrmals 

in Folge gesunken ist. 

3.2. Szenario 

Szenario Gerät / Inhalt Rolle 

Quelle Prozessor Senke 

1 Handheld • 

Desktop-PC mit Drucker • 

weitere Geräte • 

2 Handy • 

PC mit Beamer • 

Musikquelle • 

weitere Geräte • 

3 Nachrichtensendung • 

leistungsfähige Rechner • 

Smartphone • 

4 intelligenter Stromzähler • 

Steuerrechner • 

schaltbare Steckdosen • 

Tabelle 3.1.: Übersicht der Beispielszenarien mit Rollenverteilung. 

Die Ziele und Anforderungen, denen ASP gerecht werden möchte, werden im folgenden 

Abschnitt zunächst zusammengefasst. Anschließend wird das Szenario, welches den Hintergrund 

für die weiteren Untersuchungen und die durchgeführten Experimente bildet, 

genau erlä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 möchte die von Publish-Subscribe-Systemen bekannten Vorteile der 

rä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. Überblick 

Ein Konferenzraum, Hörsaal oder Büro bilden den Ausgangspunkt des untersuchten 

Szenarios. Es finden dort regelmäßig Besprechungen oder Vorlesungen statt. Die Teilnehmer 

dieser Veranstaltungen sind häufig noch lange über die Dauer der Veranstaltung 

hinaus an dem Gesagten interessiert. Dies trifft insbesondere für Interessenten zu, die 

an der Veranstaltung nicht persönlich teilnehmen konnten. Aus diesen Gründen ist es 

wünschenswert, dass die Veranstaltung aufgezeichnet wird. Es Bedarf dazu einer Infrastruktur, 

die den spontanen Mitschnitt einer Veranstaltung ermöglicht. Nach dem Ende 

der Veranstaltung müssen die Teilnehmer und weitere Interessenten einen möglichst 

komfortablen Zugriff auf die Aufzeichnung haben. 

Konkret könnte es den folgenden Ablauf geben. Ein Dozent und zwei Dutzend Studenten 

oder Gä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 Vorträge mit anschließender Diskussion. Ein an das Netzwerk 

des Hörsaals angeschlossener Computer empfängt und archiviert die Aufzeichnung automatisch 

in bester Qualität. Kurz vor Ende der Veranstaltung beendet der Dozent die 

Aufzeichnung. Einige der Studenten benutzen ihre Handys um auf die einzelnen Vorträge 

zuzugreifen. Für den zügigen Download wählen sie die in einem komprimierten Format 

angebotenen Mitschnitte. Eine Woche später sind andere Studenten in dem Hörsaal. Aus 

Interesse greifen jedoch auch einige von ihnen auf die Aufzeichnung der Vorwoche zu und 

laden sie auf ihr Mobilgerä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 für die Aufzeichnung gewählte Gerät ein. Es digitalisiert 

Sprache und gibt das Ergebnis weiter (recorder, Kürzel R in Abb. 3.1). Es handelt 

sich dabei um einen Rechner, der inklusive Mikrofon fester Bestandteil des Raumes 

ist oder um ein Mobilgerät, welches nicht ständig vor Ort ist. Ein weiterer Computer 

übernimmt die Speicherung und Archivierung der Aufnahme (storage, S). Es wird im 

folgenden davon ausgegangen, dass der Rechner über einen ausreichend großen nichtflüchtigen 

Speicher verfügt und über große Zeiträume verfügbar ist. Die Skizze nennt 

ein NAS-System (Network Attached Storage) als Beispiel. Da solche und vergleichbare 

Geräte nicht in jedem Fall über sehr große Rechenkapazitäten verfügen, wird die 

Umwandlung in ein komprimiertes Format (converter, C) auf einem dritten Rechner 

vorgenommen. Es kann sich dabei grundsätzlich um einen beliebigen, ausreichend leistungsfähigen 

Rechner handeln. Dort, wo gerade Kapazitäten frei sind, wird die Aufgabe 

28

3. Konzept 

S 

Bluetooth oder WLAN 

Smartphone, 

PDA, portabler 

Medienspieler 

R 

WLAN-Router oder -AP mit USB 

oder NAS-System 

Ethernet oder WLAN 

PC oder Server 

Notebooks, Smartphones, 

portable Medienspieler 

WLAN oder Bluetooth 

D 

C 

WLAN Bluetooth 

Abbildung 3.1.: Skizze des Szenarios mit den Rollen Aufzeichnung (R), Speicherung und 

Weitergabe (S), Umwandlung (C) und Download (D). 

ausgeführt. Die vierte Rolle, den Download eines Mitschnitts (download, D), übernehmen 

ein oder mehrere Geräte. Sie sind wie ihre Benutzer nur gelegentlich vor Ort. Darüber 

hinaus wird davon ausgegangen, dass sie keine ständige Verbindung zum Netzwerk des 

Veranstaltungsraumes haben, die möglicherweise langsam ist. Handelt es sich um mehrere 

Geräte, können diese untereinander vernetzt sein. 

Das gegebene Szenario ist beispielhaft für eine Anwendung in einer heterogenen, dynamischen 

Umgebung. Es eignet sich fü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 

Geräten wahrgenommen werden, ist das Szenario geeignet, die räumliche und zeitliche 

Entkopplung zu testen. Die transparente Umwandlung der Aufzeichnungen und die Aufbereitung 

fü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 Möglichkeiten von ASP 

zu evaluieren, ist die Heterogenität des Umfelds. Es kommen Geräte unterschiedlicher 

Leistungsklassen zum Einsatz. Diese sind über unterschiedliche Techniken miteinander 

vernetzt. Die Skizze nennt Bluetooth, WLAN und Ethernet. 

3.2.3. Variationsmöglichkeiten 

Die grundsätzliche Eignung des Szenarios zur Evaluierung von ASP wurde bereits gezeigt. 

Bei genauer Betrachtung ergeben sich Möglichkeiten das Szenario in einigen Aspekten 

zu variieren. Dazu zä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 

1 

3 

D 

4 4 

R D 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 für den Einsatz auf unterschiedlichen 

Verbindungen eignen. Die Nummern beziehen sich auf die Abbildung 3.2. Die 

Übersicht erhebt keinen Anspruch auf Vollständigkeit. 

Unterschiedliche Geräte können die vorgestellten Rollen übernehmen. Neben PCs (einschließlich 

Notebooks und Netbooks), kommen im Szenario Smartphones und eingebettete 

Systeme wie NAS-Systeme vor. Tabelle 3.3 führt einige Konstellationen auf. 

30

3. Konzept 

802.11abgn (Infrastr.) 

802.11abgn (Ad-Hoc) 

Bluetooth 

Ethernet 

Verbindungstechnik 

Verbindung 1 1 

2 2 

3 3 3 

4 4 

Tabelle 3.2.: Unterschiedliche Varianten der Vernetzung. Siehe Abb. 3.2. 

Plattform Embedded Smartphone PC 

Rolle R R 

S S 

C 

D D 

Tabelle 3.3.: Unterschiedliche Rollen können auf unterschiedlichen Plattformen ausgeführt 

werden. Siehe Abb. 3.2. 

Bei der Aufzeichnung und dem anschließenden Download von Tonmitschnitten gibt es 

zwei charakteristische Arten von Datenverkehr. Während der Aufzeichnung fallen in 

regelmäßigen, kurzen Intervallen relativ kleine Datenmengen an. Bei einer unkomprimierten 

Aufzeichnung in Telefonqualität wären dies z.B. 8 Bit/s · 8000 = 64 kBit/s. Auf 

der anderen Seite ergibt sich für einen Download eines einstündigen Vortrages in derselben 

Qualität in einem komprimierten Format mit einer angenommenen Kompressionsrate 

von 1:10 ein Datenvolumen von rund 22 MByte. Diese Datenmenge muss möglichst 

zügig auf einmal übertragen werden. 

Zusammenfassend wird festgehalten, dass je nach Hard- und Softwareplattform, Kommunikationstechnik 

und Art der Datenübertragung gänzlich unterschiedliche Bedingungen 

vorliegen. Damit stellt das Szenario eine realistische und vielseitige Ausgangsbasis für 

die Untersuchung von ASP dar. 

3.3. Abbildung auf ASP 

Für die Untersuchung von ASP wird das Szenario auf dessen Konzepte abgebildet. Im 

folgenden werden die von ASP genutzten Anwendungstypen und Ü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 Gültigkeitsdauer von Ankündigungen 

haben Einfluss auf die Leistungsfähigkeit und Zuverlä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 Übertragungskategorien 

Den in Abschnitt 3.2.2 eingeführten Rollen werden zunä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 für eine Informationsquelle. Die Rolle der Aufzeichnung nimmt 

also eine Anwendung vom Typ Quelle wahr. Umgekehrt ist der Download eines Audiomitschnitts 

mit der späteren Wiedergabe charakteristisch fü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 

über weitere Prozessoren) eine Senke. 

Die Rolle, die bislang als Speicherung oder Archivierung (Kürzel S) bezeichnet wurde, 

lä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 (gegenwärtig) verfügbare Daten 

soweit möglich in andere Daten verarbeitet. Die Rolle eines Archivs ist es jedoch Daten 

über lange Zeiträume verfü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 übernommen. 

Die Datenübertragungen lassen sich in die in Abschnitt 2.5.5 genannten Kategorien 

einordnen. Dabei müssen drei Ü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 Geräten, auf denen der Download (D) stattfindet. 

Bei der Übertragung der Mitschnitte zum Knoten, auf dem sie abgespeichert werden, 

handelt es sich um einen Strom kleiner Nachrichten 1 (Kategorie 2). Berücksichtigt man, 

1 Bei ASP heißen die Nachrichten für den Datentransport Veröffentlichungen (siehe S. 14). 

32

3. Konzept 

dass der verfügbare Speicher und die Stromversorgung des Geräts, welches die Sprache 

unmittelbar aufzeichnet und digitalisiert, stark begrenzt sein können, so ist dieser Modus 

der effektivste. 

Die Übertragung der Aufzeichnung zum Prozessor und der Download von dort, können 

als einzelne große Veröffentlichungen übertragen werden (Kategorie 3). Anzumerken ist, 

dass in [Ris09a] der Fokus auf kleinen Einzelübertragungen lag (Kategorie 1). 

Analog zu den drei unterschiedlichen Datenübertragungen, müssen mindestens drei unterschiedliche 

ASP IDs (siehe Abschnitt 2.5.1) pro durchgeführtem Mitschnitt zum Einsatz 

kommen. Andernfalls können die beteiligten Anwendungen nicht zweifelsfrei zwischen 

den Veröffentlichungen unterscheiden. Die Wahl der konkreten IDs und des Inhalts 

von Ankündigungen ist dabei anwendungsabhängig und fü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 müssen für die 

experimentelle Evaluierung von ASP angemessen berücksichtigt und umgesetzt werden. 

Die im Szenario vorkommenden Hardwareplattformen unterscheiden sich vor allem 

in der verfügbaren Rechen- und Speicherkapazität. Die vorhandene Hardware muss ausreichend 

Ressourcen bereitstellen, damit die darauf laufende Anwendung ihre Aufgabe 

erfüllen kann. Für die Sprachaufzeichnung ist ein Mikrofon erforderlich und die Netzwerkverbindung 

des Aufzeichnungsgerätes sollte ausreichend sein, um die unkomprimierten 

Daten in Echtzeit übertragen zu können. 

Für die Speicherung und Archivierung der Aufnahmen wird genügend Speicherplatz auf 

einem nicht-flüchtigen Speichermedium benötigt. Wie bereits erwähnt wurde, ist für die 

Rolle der Speicherung eine hohe Verfügbarkeit wünschenswert, damit Nutzer jederzeit 

auf vergangene Aufzeichnungen zugreifen können. Ein batteriebetriebenes Mobilgerät 

kommt somit nicht in Frage. 

Die Konvertierung der Aufzeichnungen in ein komprimiertes Format sollte möglichst 

schnell ablaufen. Das erfordert eine leistungsfähige Verbindung zwischen dem Aufzeichnungsarchiv 

und dem Konverter und eine möglichst große Rechenleistung beim Konverter, 

damit dieser die Aufgabe schnell abschließen kann. 

Wie die Hardware muss auch die Softwareumgebung gewisse Anforderungen erfüllen, 

damit ASP und die Anwendungen des Szenarios umgesetzt werden können. Die Sprachaufzeichnung 

erfordert Schnittstellen und Softwarekomponenten um auf den Strom der 

Audiodaten zugreifen und ihn verarbeiten zu können. Die Daten müssen zudem in einem 

Format vorliegen, welches die weiteren Stationen – Speicherung und Konvertierung 

– verarbeiten können. Der Konverter benötigt Software, die es ermöglicht, die Audiodaten 

zu komprimieren. Sie muss auf allen Plattformen verfügbar sein, die fü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 

ü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 für die Kommunikation des 

Brokers mit benachbarten Brokern transparent ist. Nachrichten sollen ungeachtet der 

Plattform des Nachbarn weiterverarbeitet werden können. 

Im Szenario ist beschrieben, dass einige Knoten Nachrichten über Technologie A empfangen 

und mit Technologie B an den Nachbarn weitergeben. Nur so kann die Heterogenität 

der Netzwerkverbindungen überbrückt werden. Der Broker muss grundsätzlich in der 

Lage sein, bei Bedarf und Verfügbarkeit mehrere unterschiedliche Netzwerktechnologien 

parallel nutzen zu können. Es ist Aufgabe der Netzwerkabstraktionsschicht, dem Broker 

dies zu ermöglichen. 

Zuletzt ist der NAL dafür zuständig, gewisse Dienstmerkmale bereitzustellen. Die kleinste 

Kommunikationseinheit, die ASP einsetzt, ist die Nachricht. Eine Nachricht hat einen 

definierten Typ und eine definierte Länge, die variabel sein kann. Einzelne Nachrichten 

müssen dem Broker komplett zugestellt werden. Die Fragmentierung auf Ebene von 

ASP bleibt davon unberührt. Wird eine Veröffentlichung von einem Broker in mehrere 

Nachrichten aufgeteilt, stellt der NAL die einzelnen Nachrichten dem Broker komplett 

zu. Dieser fügt sie zu einer Veröffentlichung zusammen. Weiter schützt die Netzwerkabstraktionsschicht 

die Ü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 übernommen werden kö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 verfälschen, bildet eine geeignete ASP-Anwendungsschnittstelle 

zwischen Anwendungen und dem lokalen Broker diese Operationen ab. Daneben 

sollten nur unbedingt nötige Schnittstellen existieren. Diese Schnittstellen sind 

für eine Umsetzung von ASP unerlässlich. Dazu gehört der Umgang mit Ankündigungen, 

also das Erzeugen und Empfangen. Die Beschränkung auf das Nö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 

für die weiteren Untersuchungen nicht unverändert übernommen. Die folgenden Absätze 

beschreiben die verwendete Schnittstelle. Grafik 3.3 fasst das Ergebnis zusammen. 

Die Schnittstelle für den Datenaustausch zwischen einer Anwendung und dem Broker 

ist abhä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 

Ankündigungen, noch Veröffentlichungen empfangen. 

Zum Empfang von Ankündigungen und Veröffentlichungen halten Senken und Prozessoren 

Schnittstellen bereit. Eine weitere Schnittstelle erlaubt es dem Broker die Anwendungen 

zu informieren, wenn Veröffentlichungen einer bestimmten ASP ID nicht länger 

zugestellt werden können, etwa weil sie nicht weiter angekündigt werden. Die ASP ID 

wird in Abschnitt 2.5.1 beschrieben. 

Eine Quelle kann Veröffentlichungen erzeugen und versenden (Publish) und benötigt 

dafür eine Schnittstelle. Für ASP ist es zusätzlich erforderlich, dass die Quelle den Inhalt 

von Ankündigungen setzen und die weitere Ankündigung von Veröffentlichungen 

beenden kann. 

Wichtigste Aufgabe einer Senke ist der Empfang von Veröffentlichungen. Damit dies geschehen 

kann, erhält die Anwendung Ankündigungen. In diesem Zusammenhang wird das 

Konzept der Filter, wie es in Abschnitt 2.5.3 beschrieben wird, unverändert übernommen. 

Der Broker erhält daher eine Schnittstelle über die die Senke den Filter festlegen kann. 

Weiter sind Schnittstellen vorgesehen, um Veröffentlichungen zu abonnieren und Abonnements 

wieder zu kündigen. Die für das Abonnement nötigen Informationen erhält die 

Senke als Teil der Ankündigungen. 

Prozessoren empfangen und versenden Veröffentlichungen. Prozessoren legen über eine 

separate Schnittstelle, die sich von der von Quellen genutzten Schnittstelle unterscheidet, 

den Inhalt von Ankündigungen fest. Auf die gleiche Weise teilen sie dem Broker mit, 

welche Veröffentlichungen sie benötigen, um aus ihnen eine neue Veröffentlichung erzeugen 

zu können. Für die korrekte Berechnung der Metrik ist es nötig, dass Prozessoren 

die Dauer der Operation abschätzen und das Ergebnis dem Broker ebenfalls mitteilen. 

Die Metrik wird in Abschnitt 3.4 ausfü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, ü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 abläuft, wird in den Abschnitten 2.5.1 und 2.5.2 beschrieben. Es 

bleiben jedoch weitere Punkte offen. Erst wenn sie geklärt sind, kann ASP erfolgreich 

implementiert werden. 

Einer dieser Punkte betrifft Prozessoren. Ein Prozessor verarbeitet Veröffentlichungen 

(P1, P2 usw.) anderer Prozessoren oder Quellen in neue Veröffentlichungen wie zum 

Beispiel P ′ . Damit die Veröffentlichungen Pi (i ≥ 1) zum Prozessor gelangen, müssen 

sie abonniert werden. Bislang wurde keine Festlegung getroffen, wann und auf welche 

Weise dies geschehen soll. Es gibt zwei Möglichkeiten. Bei der ersten abonniert die Prozessoranwendung 

selbstständig jede der benötigten Veröffentlichungen. Dieser Ansatz 

widerspricht jedoch dem Kerngedanken von ASP. Abonnieren Prozessoren eigenmächtig 

Veröffentlichungen, so stammen diese möglicherweise von weiteren Prozessoren. Diese 

anderen Prozessoren abonnieren wiederum Veröffentlichungen usw. Im Ergebnis werden 

alle Quellen, deren Veröffentlichungen direkt oder indirekt von einem Prozessor verarbeitet 

werden, aufgefordert ihre Veröffentlichungen zu übertragen. Das Netzwerk wird 

belastet und die Entscheidung der Middleware, welcher der günstigste Pfad ist, ist praktisch 

irrelevant. Die Alternative zu diesem Verhalten ist, dass der Broker stellvertretend 

für eine Prozessoranwendung die Veröffentlichungen abonniert. Dies hat den Vorteil, dass 

der Broker jederzeit weiß, ob Abonnements für die Veröffentlichungen P ′ vorliegen. Liegen 

keine Abonnements vor, müssen auch P1, P2 usw. nicht abonniert werden. Dies hat 

zur Folge, dass das Netzwerk und der Prozessor nicht unnötig belastet werden. Dies gilt 

umgekehrt auch, wenn das Interesse an den Veröffentlichungen P ′ versiegt. Dann kündigt 

der Broker die Abonnements von P1 usw. Der Prozessor wird nicht länger belastet. 

Ein weiterer Komplex betrifft die Erkennung und Reparatur von Pfaden. Sie werden 

mit Ankündigungen und Abonnements aufgebaut. Bricht eine der Verbindungen entlang 

eines Pfades ab, wird eine Störungsmeldung erzeugt. Abschnitt 2.5.2 schildert die 

Abläufe genauer. Unklar ist, wie ein Broker angemessen auf eine verlängerte Ankündigung 

reagieren soll. Da Störungsmeldungen gezielt an den Prozessor oder die Quelle, die 

die Ankündigungen erzeugt, weitergeleitet werden, wissen nicht alle Broker entlang des 

Pfades, dass er repariert werden muss. Insbesondere dürfen sie sich nicht darauf verlassen, 

dass die folgende Ankündigung vom selben Nachbarn stammen wird, von dem die 

letzte Ankündigung empfangen und mit einem Abonnement quittiert wurde. Damit Pfade 

repariert werden können, müssen Broker zunächst jede Ankündigung übernehmen, 

die aktueller als die vorangegangene ist, ungeachtet der Kosten, die die Metrik liefert. 

Dies kann zur unnötigen Änderung von Routen (Pfaden) führen. Insbesondere könnte es 

bedeuten, dass eine schlechter Pfad gegenüber einem besseren bevorzugt wird, weil die 

Ankündigungen auf dem schlechten Pfad (kurzfristig) schneller zugestellt wurden als auf 

dem besseren Pfad. Es gibt unterschiedliche Strategien, um die Stabilität von Pfaden 

(im Sinne der Anzahl und Reihenfolge der Zwischenstationen) zu erhöhen. Grundlage 

der Ansätze ist die verzögerte Aktivierung von Pfaden. Trifft eine Ankündigung Ax mit 

den Kosten c beim Broker b ein, beginnt ein kurzes Zeitintervall. Trifft Ax ′ mit derselben 

Sequenznummer wie Ax aber niedrigeren Kosten c ′ < c innerhalb des Intervalls ein, 

36

3. Konzept 

gilt Ax ′ als beste Ankündigung. Erst bei Ablauf des Intervalls wird das Abonnement, 

welches nötig ist, um den Pfad zu aktivieren, an den Absender der besten Ankündigung 

versendet. Soll der Pfad besonders stabil sein, genügt es, nicht die vermeintlich beste 

Ankündigung zu übernehmen, sondern während des gesamten Intervalls auf die Ankunft 

derjenigen Ankündigung zu warten, die vom selben Nachbarn stammt wie die vorherige. 

Sie ist dann ausschlaggebend für den Versand des Abonnements. Dieses Verfahren wird 

im weiteren Verlauf eingesetzt. Eine weitere Maßnahme ist, bessere Ankündigungen nur 

dann zu übernehmen, wenn sie signifikant – das heißt z.B. mindestens 10 % – besser sind 

als die vorherige. Weitere Ansätze werden hier nicht verfolgt. Für die experimentelle Evaluation 

ist es vorteilhaft, wenn ASP nicht in besonderem Maße über den bereits in der 

Literatur beschriebenen Umfang hinaus weiterentwickelt wird. Jede Optimierung oder 

Erweiterung könnte bislang unbekannte Folgen haben. Das würde die Übertragbarkeit 

der Erkenntnisse auf das existierende ASP-Konzept einschränken. Komplexe Erweiterungen 

sollten zunächst in separaten Untersuchungen oder Simulationen betrachtet werden. 

Verbunden mit der Stabilisierung von Pfaden ist ein weiterer Effekt. Angenommen, der 

Verlauf eines aktiven Pfades ändert sich. Werden zeitgleich Veröffentlichungen entlang 

des alten Pfades übertragen, kann dies dazu führen, dass einzelne Veröffentlichungen 

verloren gehen. Die Grafik 3.4 illustriert das Phänomen an einem Beispiel. Als Schutz 

gegen diese Art von Datenverlust, wird ein Verfahren eingeführt, das hier als Fading 

bezeichnet wird. Ä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 zusätzliches Abonnement an Na. Auf diese Weise bleibt der alte Pfad länger aktiv. 

Veröffentlichungen, die noch auf dem alten Pfad unterwegs sind, kö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 länger aktiviert. 

3.3.5. Caching 

Eine wichtige Eigenschaft von Publish-Subscribe-Systemen wie ASP ist die zeitliche Entkopplung. 

Es sind Maßnahmen nötig, um diese Eigenschaft sicherzustellen. Von großer 

Bedeutung ist dabei das Caching. Im Falle von ASP ist vor allem das Caching von Veröffentlichungen 

wichtig, doch auch das Caching von Ankündigungen bietet Vorteile. Ohne 

jede Zwischenspeicherung von Veröffentlichungen, käme in vielen Situationen keine zeitliche 

Entkopplung von Publisher und Subscriber zustande. Angenommen, ein Publisher 

veröffentlicht Daten. Die Subscriber, die ihr Interesse geäußert haben, erhalten die Veröffentlichung. 

Bei ASP sind das jene Prozessoren oder Senken, die über ihre Broker Pfade 

für diese Veröffentlichung aktiviert haben. Alle anderen potenziellen Subscriber, die 

(vorübergehend) ihr Interesse an der Veröffentlichung nicht mitteilen konnten, erhalten 

sie nicht. In einem Umfeld wie dem Szenario aus Abschnitt 3.2 sind Verbindungsabbrüche 

nicht ausgeschlossen. Sie verhindern unter Umständen, dass Subscriber Pfade 

aktivieren, wenn Abonnements verloren gehen oder wegen Sendewiederholungen zu spät 

beim Publisher eintreffen. 

37

3. Konzept 

A 

A 

B 

B 

C 

D 

C 

D 

Veröffentlichung 

Verlust der 

Veröffentlichung 

Abbildung 3.4.: Durch Routenänderungen kann es zum Verlust von Veröffentlichungen 

kommen. Wird ein aktiver Pfad (durchgezogene Linie; von A nach O) 

durch einen anderen ersetzt, können Nachrichten, die noch auf dem alten 

Pfad unterwegs sind, verloren gehen (unten). 

E 

F 

E 

F 

O 

O 

38

3. Konzept 

Außerdem kann es vorkommen, dass einzelne Anwendungen oder Geräte erst nach einer 

Veröffentlichung aktiviert werden. Im Szenario wäre dies zum Beispiel dann der Fall, 

wenn zunächst ein Benutzer einen Mitschnitt P auf sein Gerät herunterlädt. In diesem 

Fall hat der Audiokonverter (Prozessor) eine Veröffentlichung erzeugt und verschickt. 

Möchte ein weiterer Nutzer später denselben Mitschnitt herunterladen, kann er einen 

aktiven Pfad aufbauen, denn Ankündigungen versendet der Prozessor nach wie vor. War 

der Pfad zum Zeitpunkt der Veröffentlichung nicht aktiv, weil der Benutzer gar nicht 

anwesend war, empfängt er die Veröffentlichung nicht. Der Grund ist, dass in Publish- 

Subscribe-Systemen nicht vorgesehen ist, dass eine Anwendung ihre Veröffentlichung 

gezielt erneut versendet. Die Nachrichtenzustellung ist allein Aufgabe der Broker. Für 

Publisher und Subscriber ist sie transparent. Ein Broker kann die Veröffentlichung nur 

dann zustellen, wenn er über eine Kopie von P verfügt. Daraus folgt, dass die Umsetzung 

eines ASP-Systems zwingend Caches für Veröffentlichungen bereithalten muss. Werden 

Pfade nach dem Versand einer oder mehrerer Veröffentlichungen aktiv, werden diese 

Veröffentlichungen aus dem Cache zugestellt. Im einfachsten Fall, speichert jeder Broker 

die Verö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 Veröffentlichungen, neuen Veröffentlichungen und Veröffentlichungen aus 

Caches unterscheiden. Dazu sind Sequenznummern für Veröffentlichungen vorgesehen. 

Um das Netzwerk nicht mit überflüssigen Veröffentlichungen aus Caches zu belasten, ist 

es hilfreich, wenn ein Broker zwischen aktiven Pfaden derselben ASP ID unterscheiden 

kann. Es wird vorgeschlagen, dafür die bereits in [Ris09a] eingeführten Subscriber IDs 

zu nutzen. Für den dort ursprünglich genannten Zweck, mehrere Subscriber an einem 

Broker zu unterscheiden, sind sie in dieser Form ausdrücklich nicht erforderlich. Die Subscriber 

ID wird in dem hier konzipierten System also genutzt, um aktive Pfade, die von 

unterschiedlichen Brokern ausgehen, unterscheiden zu können. 

Betrachtet man neben Veröffentlichungen auch Ankündigungen, ergibt sich ein weiterer 

interessanter Anwendungsfall für Caches. Er betrifft die Eingliederung von neuen Knoten 

(Brokern) in das Netzwerk. Werden Ankündigungen nicht zwischengespeichert, muss 

ein neu hinzugekommener Broker warten, bis alle im System existierenden Ankündigungen 

verlängert wurden. Der Zeitraum ist von der Gültigkeitsdauer der Ankündigungen 

abhängig. Cachen Broker jedoch Ankündigungen, können sie einem neuen Nachbarn 

sofort alle ihnen bekannten Ankündigungen übergeben. Dadurch wird die Latenz verringert, 

mit der der neue Broker sein Interesse an den Veröffentlichungen verbreiten kann. 

Dem steht als Nachteil gegenüber, dass ein kleiner Teilbereich des Netzwerks kurzzeitig 

stärker belastet wird. Lernen mehrere Broker zeitgleich einen neuen Nachbarbroker kennen, 

werden die Ankündigungen zudem redundant verschickt. Der Vorteil der geringen 

Latenz überwiegt die Nachteile nach Meinung des Autors. Das Caching von Ankü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 Leistungsfä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 

dafür konzipiert wurden. Es folgt eine Betrachtung der Faktoren, die in dem konkreten 

Szenario (siehe Abschnitt 3.2) die Übertragungsleistung beeinflussen. Eine Metrik muss 

diese Faktoren angemessen berü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 fü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 Übertragungskapazität 

und die Verlustrate zwei zentrale Verbindungseigenschaften. Die Übertragungskapazität 

einer Verbindung zwischen zwei benachbarten Stationen, also die Datenmenge, 

die in einem bestimmten Zeitintervall maximal übertragen werden kann, begrenzt 

den Datenfluss nach oben. Je höher die Kapazität, umso schneller können Daten 

ausgetauscht werden. Die Verlustrate nimmt Einfluss auf die verfügbare Kapazität und 

die Übertragungslatenz einer Verbindung. Angenommen, eine Netzwerktechnologie verwendet 

einen Mechanismus aus Bestä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 führt der Verlust von Datenpaketen 

unmittelbar zu einer Erhöhung der Latenz, weil verlorene Daten erneut übertragen werden 

müssen. Analog sinkt die verfügbare Übertragungskapazität, wenn Übertragungsverluste 

auftreten. Wegen Sendewiederholungen werden effektiv weniger Nutzdaten pro 

Zeiteinheit übertragen. 

Wegen ihrer großen Bedeutung, sollte eine Metrik für ASP die Übertragungskapazität 

und die Verlustrate vorrangig berücksichtigen. Die Metrik sollte es ermöglichen, zwischen 

unterschiedlichen Pfaden denjenigen Pfad zu wählen, der eine hohe Kapazität aufweist 

und dessen einzelne Verbindungen möglichst verlustarm sind. Letzteres hilft die Latenz 

zu minimieren und die erzielbare Übertragungsrate zu maximieren. 

Symmetrie von Verbindungen (nicht Routen oder Pfaden) ist für das Funktionieren 

von ASP notwendig. Der Grund ist die Art und Weise wie ASP aktive Pfade etabliert. 

Empfä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 Ankündigung 

Ax mit den minimalen Kosten empfangen hat. Das gilt analog für die Verbreitung von 

Veröffentlichungen, denn sie werden an Nachbarn gesendet, von denen Abonnements 

empfangen wurden. Die Hop-Count-Metrik erlaubt keine Aussagen über die Symmetrie 

von Verbindungen. Sie scheidet daher für den Einsatz in ASP aus. 

40

3. Konzept 

Neben Bandbreite, Verlustrate und Symmetrie einer Verbindung, hat die Auslastung 

Einfluss auf die Leistungsfähigkeit. Keine der in Abschitt 2.7 genannten Metriken berücksichtigt 

unmittelbar die Auslastung einer Verbindung. Dadurch wird das Oszillieren 

von Routen vermieden [DABM05]. Metriken wie ETT, die die Kapazität berücksichtigen, 

können für Oszillieren anfällig werden, wenn sie die verfügbare Bandbreite und 

damit auch die Auslastung ausmessen [DPZ04]. Wird die Verbindungsauslastung nicht 

berü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 überlastet wird. 

Die ebenfalls in Abschnitt 2.7 erläuterten Phänomene Intra- und Inter-Flow-Interferenz 

können in einem Netzwerk auftreten, sobald mehr als eine Funkverbindung im selben 

Frequenzband existiert. Davon ist im Szenario auszugehen (siehe Abschnitt 3.2). Die 

Phänomene kö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 beschränktes Wissen über die Topologie des Netzwerkes. Sie kennen lediglich ihre 

Nachbarn. Um Inter-Flow-Interferenz vermeiden zu können, sind jedoch sehr detaillierte 

Informationen über den Zustand eines größeren Teils des Netzwerks erforderlich. ASP 

sieht keinen Mechanismus vor, solche Informationen auszutauschen oder zu erheben. Der 

Einsatz eines Protokolls zum Austausch solcher Statusinformationen würde das Netzwerk 

zusätzlich belasten. Eine Metrik wie MIC ist für den Einsatz in ASP ungeeignet, 

da die nötigen Informationen zur Bewertung der Pfade nicht zur Verfügung stehen. Das 

heterogene Umfeld für das ASP konzipiert ist, erschwert zusä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. Ähnlich wie MIC benötigt WCETT detailliertes 

Wissen über die Eigenschaften der Verbindungen entlang eines Pfades. Die 

Wechselwirkungen zwischen einzelnen Übertragungstechnologien müssten zudem in geeigneter 

Weise modelliert werden und in sämtlichen ASP-Stationen vorliegen. Aus den 

genannten Gründen eignet sich WCETT nicht für den Einsatz in ASP. 

Verglichen mit WCETT und MIC werden zur Berechnung von ETX und ETT wenige 

Daten benötigt. Konkret sind dies bei ETX die Verlustrate in Sende- und Empfangsrichtung 

zwischen zwei benachbarten Stationen. Voraussetzung für die Berechnung von ETT 

sind zusätzlich Informationen über die Bandbreite einer Verbindung und die Größe der 

zu sendenden Pakete. Verlustrate und Bandbreite betreffen ausdrücklich Paare jeweils 

unmittelbarer Nachbarn. Damit sind die Metriken kompatibel zu ASP, welches sich ausdrücklich 

auf Wissen über Nachbarschaftsbeziehungen beschränkt. ETT wird in [Ris09b] 

als Grundlage für eine Metrik gewählt. 

41

3. Konzept 

3.4.2. Datenverarbeitung 

Auf die Geschwindigkeit der Verarbeitung von Veröffentlichungen durch Prozessoren 

haben die Anzahl und Größe der Eingabeveröffentlichungen großen Einfluss. Große 

Eingabedaten oder eine Vielzahl kleiner Veröffentlichungen können je nach Hardware 

nicht im Primärspeicher bearbeitet werden. Unabhängig davon ist der Verarbeitungsaufwand 

stark anwendungsabhängig. Der ASP-Broker sollte bei der Ermittlung der Verarbeitungsmetrik 

daher auf Informationen zurückgreifen, die von der Prozessoranwendung 

stammen. In [Ris09b] wird eine zeitbasierte Verarbeitungsmetrik angeregt. Machen 

die Prozessoranwendungen Schätzungen über die zu erwartende Verarbeitungszeit, 

so werden die beiden zuletzt genannten Punkte kombiniert. Auf welcher Grundlage eine 

Prozessoranwendung die Schä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 Leistungsfähigkeit des Systems abzuschätzen. 

3.4.3. Metrik für ASP 

Eine Metrik, die für den Einsatz in ASP geeignet ist, verknü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 ermöglicht es, genauere 

Aussagen über die Qualität einer Verbindung zu treffen als ETX. Deshalb soll die Metrik 

ETT als ein Baustein für eine Metrik für ASP dienen. Da die Kontrollnachrichten 

von ASP kompakt sind und Veröffentlichungen einen sehr geringen Datenumfang kleiner 

oder gleich 100 Byte haben können, tritt insbesondere bei hohen Bandbreiten ein Problem 

auf. Rechnerisch beträgt die Übertragungsdauer für 100 Byte bei 100 MBit/s nur 

etwa 0,08 ms. Ein vernachlässigbar kleiner Wert verglichen mit Latenzen im Millisekundenbereich. 

ETT verliert unter diesen Umständen an Aussagekraft. Aus diesem Grund 

wird die Latenz einer Verbindung in Form der RTT (round trip time) zusätzlich für die 

Berechnung der Verbindungskosten herangezogen. 

Als Metrik für die Datenverarbeitung soll die geschätzte Dauer zur Erzeugung einer 

Veröffentlichung durch den Prozessor dienen. Wird eine Veröffentlichung P ′ aus den 

Veröffentlichungen P1, P2 bis Pn erzeugt, so beziffert die Prozessoranwendung den Zeitraum 

tproc, der wahrscheinlich zwischen dem Zeitpunkt, zu dem alle n Eingabeveröffentlichungen 

vorliegen und dem Zeitpunkt, bis P ′ 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� 

d(ei) (3.1) 

i=1 

42

3. Konzept 

P1 trifft ein 

P2 trifft ein 

P4 trifft ein 

P3 trifft ein 

t0 

Zeit 

Abbildung 3.5.: Die Zeit für die Umwandlung von P1 bis P4 nach P ′ ergibt sich als tproc = 

t1 − t0. 

P ’ steht bereit 

Für die Kosten einzelner Kanten (Verbindungen) e ergibt sich: 

d(e) = trtt 

2 

+ ETT + tproc 

(3.2) 

t1 

Bei von Prozessoren verarbeiteten Veröffentlichungen ist zusätzlich die Summe der Kosten 

aller Ausgangsveröffentlichungen zu berücksichtigen. 

d(e) = trtt 

2 + ETT + tproc + 

k� 

j=1 

ETT berechnet sich nach der auf Seite 18 genannten Formel. 

mj 

(3.3) 

Die Metrik, die die Gleichungen 3.1 und 3.3 definieren, unterscheidet sich von der in 

[Ris09b] vorgeschlagenen Metrik. Die hier verwendete Metrik berücksichtigt Änderungen 

der Größe von Veröffentlichungen nicht ausdrücklich. Die gewä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 Größe einzelner Veröffentlichungen bei der Berechnung der 

Metrik berücksichtigt wird. Erst wenn mehrere Prozessoren unterschiedlich verknüpft 

werden können, ist die genaue Größe von Veröffentlichungen entscheidend. Für umfangreichere 

Szenarien könnte die exakte Größe bei der Berechnung der ETT einfließen. Dafür 

wäre es notwendig, dass die (voraussichtliche) Größe von Veröffentlichungen mit den zugehörigen 

Ankündigungen verbreitet wird. Das ist bislang für ASP nicht vorgesehen. Der 

Ansatz wird hier aus den genannten Gründen nicht weiter verfolgt. 

43

4. Implementierung 


Bislang existierte keine Implementierung von ASP für ein reales System. Der gesamte 

ASP-Stack wurde daher neu implementiert. Für die vollständige Umsetzung des Szenarios 

wurden die Anwendungen ebenfalls neu implementiert oder falls bestehende Lösungen 

verfü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 für die Kommunikation mit Brokern 

auf benachbarten Knoten. Anwendungen sind ü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 für die Wahl von Java waren die 

hohe Codeportabilität, die Verfügbarkeit der Laufzeitumgebung auf vielen gängigen Betriebssystemen 

und die umfangreiche Standardbibliothek (siehe [Ull07]). Ein weiteres 

Argument für Java war zunächst die Option, die Software ohne eine komplette Neuimplementierung 

auf Mobilgeräte mit der Plattform J2ME zu portieren (siehe [BM06]). 

Dieses Vorhaben wurde wegen des hohen zu erwartenden Zeitaufwands verworfen. Aus 

Rücksicht auf das für die Versuche verfü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 Absätzen umrissen. 

44


4.2.1. Rekorder 

Die Anwendung zur Sprachaufnahme nutzt die Java Sound API für den Zugriff auf ein 

vorhandenes Mikrofon [Ora10]. Sie erlaubt die Aufzeichnung von Sprache in einem unkomprimierten 

Format in einer vorgegebenen Qualität. Die Aufzeichnung wird mit ASP 

an interessierte Subscriber übertragen. Die Ankündigungen enthalten das Datum der 

Aufzeichnung und Informationen zum Format der Audiodaten. Für die Übertragung 

(Veröffentlichung) wird der Strom der Audiodaten in Abschnitte von je ca. 1280 Byte 

aufgeteilt. Jeder dieser Abschnitte wird eigenständig veröffentlicht. Im Rahmen einer 

Aufzeichnung werden je nach Länge hunderte oder tausende Verö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 verö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 Durchführung der Experimente. Nicht 

zuletzt lässt sich die Audioaufnahme an Geräten simulieren, die Sprache nicht aufzeichnen 

können. 

4.2.2. Speicherung 

Das Programm zur Speicherung empfä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 prüft zunächst den Inhalt der Ankündigungen. 

Bei Interesse abonniert die Anwendung die Veröffentlichungen und schreibt sie 

in eine Datei. Die Aufzeichnung wird beendet, wenn die Middleware der Senke meldet, 

dass Veröffentlichungen mit der ASP ID nicht länger zu erwarten sind. Die Informationen 

über das Aufzeichnungsdatum werden ebenfalls abgespeichert. Regelmäßig überprüft die 

Quelle der Anwendung, ob neue Aufzeichnungen abgespeichert wurden. Liegt eine neue 

Aufzeichnung vor, wird diese umgehend angekündigt. Die gespeicherte Aufzeichnung 

wird als eine große Veröffentlichung veröffentlicht. 

4.2.3. Konverter 

Die Anwendung zum Umwandeln der Audiodaten in ein komprimiertes Format untersucht 

ständig eingehende Ankündigungen. Kann das Programm die angekündigten Veröffentlichungen 

einer ASP ID verarbeiten, macht es eine entsprechende Ankündigung der 

verarbeiteten Daten. Dabei schätzt die Anwendung auch die zu erwartende Dauer der 

Umwandlung ab. Sie benutzt dazu die Dauer der angekündigten Audiodatei als Grundlage. 

Diese Dauer wird durch die bekannte Umwandlungsgeschwindigkeit dividiert. Zum 

Beispiel beträgt der geschätzte Aufwand für die Umwandlung einer fünf Minuten langen 

Aufzeichnung auf einem Rechner, der mit 20facher Geschwindigkeit umwandeln kann 

5·60s 

20 = 15s. Der konkrete Geschwindigkeitsfaktor wird über eine Konfigurationsdatei 

festgelegt. 

45


Geht eine gespeicherte Aufnahme ein, wird sie als Datei zwischengespeichert. Die Komprimierung 

übernimmt ein externes Programm. Fü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 gewählt, weil es kostenlos für die 

Betriebssysteme Windows, Mac OS X und Linux auf unterschiedlichen Architekturen 

(x64/amd64, x86, ppc) verfügbar ist. Nach der Umwandlung wird das Ergebnis den 

interessierten Subscribern in Form einer Veröffentlichung zur Verfügung gestellt. 

4.2.4. Download 

Das Programm zum Download enthält nur die nötigsten Funktionen. Es zeigt dem Benutzer 

alle derzeit angekündigten ASP IDs und auf Wunsch den Inhalt der entsprechenden 

Ankündigungen an. Wählt der Anwender eine ID für den Download aus, abonniert das 

Programm die Veröffentlichung. Die erste Veröffentlichung dieser ID schreibt es in eine 

Datei und kü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 während der Entwicklung der Middleware zu Testund 

Diagnosezwecken eingesetzt. Eine der dabei entstandenen Anwendungen, kam auch 

wä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. Ankündigungen werden auf dem Bildschirm ausgegeben, jedoch nie abonniert. 

Die ASP-Middleware dieser Anwendung verhä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, überwacht Ankündigungen und stellt den registrierten 

Anwendungen die abonnierten Veröffentlichungen zur Verfügung. 

4.3.1. Multithreading 

Die Aufgaben des Brokers sind auf mehrere Threads verteilt. Es gibt je einen Thread 

für die Nachrichtenverarbeitung in Sende- und Empfangsrichtung. Daneben existieren 

zwei weitere Threads, die regelmäßige bzw. zeitlich verzögerte Operationen ausführen. 

1 http://www.vorbis.com/ 

46


Der Thread, der die empfangenen Nachrichten bearbeitet, ist zudem für das Starten und 

Beenden der Middleware verantwortlich. Zu seinen weiteren Aufgaben zählen das Zusammensetzen 

fragmentierter Nachrichten und die Übergabe von Ankündigungen und 

Veröffentlichungen an die beim Broker registrierten Anwendungen. Der ” Sender“ genannte 

Thread fragmentiert Nachrichten falls nötig, und übergibt die Nachrichten an 

die NAL-Implementierung. 

Der Thread ” TimeoutMonitor“ überwacht die Gültigkeit eingehender und ausgehender 

Ankündigungen. Sobald eine ausgehende Ankündigung zu verfallen droht, löst dieser 

Thread die Verlängerung der Ankündigung aus. Für die Implementierung wurde ein 

Wert von 80 % der Gültigkeit der Ankündigung gewählt. Hat eine Ankündigung zum 

Beispiel eine Gültigkeit von 10 s, wird sie nach 8 s automatisch verlängert. Wird eine 

eingehende Ankündigung nicht rechtzeitig verlängert, wird dies protokolliert und die 

bekannte Ankündigung wird komplett verworfen. Lokale Anwendungen, die Veröffentlichungen 

der betroffenen ASP ID abonniert haben, werden benachrichtigt. 

Der vierte Thread löst nach einer geringen Verzögerung den Versand von Abonnements 

aus. Auf diese Weise muss der Thread, der das Abonnement ursprünglich auslöst, seine 

Ausführung nicht pausieren. Die Verzögerung ist auf 100 ms festgelegt. 

4.3.2. Priorisierung 

Zum Aufbau aktiver Pfade verwendet ASP Ankündigungen und Abonnements (siehe 

Abschnitt 2.5.2). Die Ankündigungen werden regelmäßig aktualisiert. Erreicht eine Folgeankündigung 

einen Broker zu spät, hat dieser die Ankündigung und alle mit ihr 

verbundenen Pfade bereits verworfen. Damit Ankündigungen mit möglichst niedriger 

Verzögerung im Netz geflutet werden, werden Kontrollnachrichten und Veröffentlichungen 

unterschiedlich priorisiert. Dadurch wird vermieden, dass die Übertragung einer 

großen Veröffentlichung (bzw. ihrer Fragmente) die rechtzeitige Zustellung von Ankündigungen 

und anderen Kontrollnachrichten verhindert. 

Jede ausgehende oder weiterzuleitende Nachricht wird innerhalb des Brokers in genau 

eine von zwei Warteschlangen eingefügt. Veröffentlichungen werden an die eine, alle 

anderen Nachrichten an die andere Warteschlange angehängt. Der zuständige Thread 

bearbeitet immer erst die Warteschlange mit den Kontrollnachrichten und erst wenn 

sie leer ist, wird geprüft, ob in der zweiten Warteschlange Veröffentlichungen sind, die 

bearbeitet werden müssen. 

4.3.3. Fragmentierung 

Die Fragmentierung von Nachrichten wird getrennt für jeden Nachbarn vorgenommen. 

Der Broker kann dazu für jeden einzelnen Nachbarn die MTU (maximum transfer unit) 

erfragen. Veröffentlichungen werden erst dann fragmentiert, wenn sie größer als die MTU 

sind. Kontrollnachrichten werden generell nicht fragmentiert. Sind sie zu groß, werden 

47


sie verworfen. Die Fragmentierung wurde so implementiert, dass eine eingehende, fragmentierte 

Veröffentlichung an jedem Broker zusammengesetzt wird. Erst danach wird 

sie bei Bedarf erneut fragmentiert und weitergeleitet. Dadurch wird vermieden, dass unvollständige 

Veröffentlichungen voreilig weitergeleitet werden und das Netzwerk unnötig 

belasten. Entlang jeder Verbindung wird zudem stets die höchstmögliche MTU verwendet. 

Im Gegenzug steigt die Übertragungslatenz jedoch an. Die Reihenfolge, in der die 

Fragmente einer Verö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 zä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 über eine Konfigurationsdatei festgelegt 

werden. 

4.5. NAL 

Die Netzwerkabstraktionsschicht wurde getrennt für Bluetooth auf der einen und Ethernet 

und WLAN auf der anderen Seite implementiert. Die beiden Implementierungen 

werden vom Broker über identische Schnittstellen angesprochen und auch in der Gegenrichtung 

werden dieselben Schnittstellen verwendet. Beide Implementierungen lassen 

sich unabhängig voneinander oder parallel betreiben. Über eine Konfigurationsdatei des 

Brokers lässt sich festlegen, welche NAL-Implementierung(en) geladen und verwendet 

werden. Damit die Middleware den Betrieb aufnimmt, müssen alle konfigurierten NAL- 

Implementierungen korrekt starten. 

In den nächsten Unterabschnitten werden die beiden Implementierungen genauer vorgestellt. 

4.5.1. Priorisierung 

Die in Abschnitt 4.3.2 beschriebene Priorisierung von Kontrollnachrichten und Veröffentlichungen 

wird in beiden NAL-Implementierungen fortgesetzt. Kontrollnachrichten 

werden mit einer höheren Priorität behandelt als Veröffentlichungen. Es sind Implementierungen 

der Netzwerkabstraktionsschicht denkbar, die anders vorgehen, um Kontrollnachrichten 

zügig zu verbreiten. In der vorliegenden Implementierung wurde darauf jedoch 

verzichtet und auf dasselbe Verfahren zurückgegriffen, dass sich im Broker bewährt 

hat. 

48


4.5.2. Ethernet und WLAN via UDP 

Die NAL-Implementierung für Ethernet und WLAN basiert auf UDP/IP. Die fü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 für UDP 

wird im folgenden als UdpNAL bezeichnet. 

ASP wurde so konzipiert, dass die Netzwerkabstraktionsschicht von beliebigen Techniken 

der Sicherungsschicht (OSI-Layer 2) oder höher abstrahiert [Ris09a]. Um den Implementierungsaufwand 

zu reduzieren, wurde entschieden, die Implementierung des NAL 

für Ethernet und WLAN auf UDP/IP aufzubauen. Mit der Socket-Schnittstelle existiert 

eine verbreitete API für die Datenü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 über der Sicherungsschicht angesiedelt. Es wurde soweit wie mö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 Fähigkeit von IP, zwischen unterschiedlichen 

Netzen zu routen, nicht genutzt. Die Kommunikation über UDP beruht 

in der Implementierung, wie von ASP gefordert, auf Nachbarschaftsbeziehungen. 

Um Nachbarn zu erkennen, sendet der UdpNAL in regelmäßigen Abständen spezielle 

Nachrichten per Broadcast an das eigene Subnetz aus. Je nach Konfiguration wird dafür 

eine gerichtete oder die eingeschränkte Broadcastadresse genutzt (siehe Abschnitt 2.8.1). 

Diese regelmäßigen Signale wurden mit der Ermittlung der Verlustraten in Sende- und 

Empfangsrichtung verknüpft. Die Raten werden ermittelt, damit die Kosten der Verbindungen 

berechnet werden können. Ferner ermittelt der UdpNAL eigenständig die RTT 

(round trip time) zu allen bekannten Nachbarn. Wird von einem Nachbarn über einen 

längeren Zeitraum gar nichts empfangen, gilt dieser Nachbar als verloren. 

Eine weitere Aufgabe des UdpNAL ist die Sicherung der Übertragungen zu den Nachbarn. 

Fü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. Übertragungen sind daher langsam. Es ist davon 

auszugehen, dass der Einsatz von TCP/IP dieses Problem behoben hä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 ausgeführt. Andere Aktionen, wie die Messung der Verlustrate, müssen 

in regelmäßigen zeitlichen Abständen ausgeführt werden und wurden deshalb ebenfalls 

in eigene Threads ausgelagert. 

49


4.5.3. Bluetooth via OBEX 

Die Implementierung der Bluetooth-Netzwerkabstraktionsschicht wird nachfolgend kurz 

als BtNAL bezeichnet. Für den Zugriff auf die Bluetooth-Hard- und Software nutzt sie 

die in JSR-82 spezifizierten Schnittstellen [Mot08]. Um sie zur Laufzeit nutzen zu können, 

wird ein Bluetooth-Stack für Java benötigt, der diese Spezifikation implementiert. Die 

implementierte Middleware verwendet dazu die freie Software BlueCove 2 . Der Stack 

wurde während der Entwicklung der ASP-Middleware erfolgreich auf allen genutzten 

Plattformen eingesetzt und funktionierte auch mit unterschiedlicher Bluetooth-Hardware 

ohne nennenswerte Probleme. 

Für die Datenübertragung verwendet der BtNAL OBEX auf Grundlage von GOEP (siehe 

Abschnitt 2.8.4). Mö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 übertragen. 

Der Client nutzt GET um die Übertragungslatenz (RTT) zwischen den beiden Bluetooth- 

Nachbarn zu ermitteln. 

Der BtNAL scannt die Umgebung periodisch nach neu hinzugekommenen Bluetooth- 

Geräten. Da die Scans sehr zeitintensiv sind und andere Übertragungen stören können, 

kommt ein adaptives Verfahren zum Einsatz. Der zeitliche Abstand zwischen zwei aufeinanderfolgenden 

Scans wird beträchtlich erhöht, sobald mindestens ein anderes Bluetooth- 

Gerät bekannt ist, auf dem die ASP-Middleware erreicht werden konnte. Der BtNAL 

nimmt keinen Einfluss auf die Sichtbarkeit des genutzten Bluetooth-Adapters bezüglich 

Inquiry Scans. Der Modus ist daher bei Bedarf mit den Mitteln des Betriebssystems zu 

konfigurieren. 

Ähnlich wie beim UdpNAL werden auch die Aufgaben des BtNAL von mehreren Threads 

gemeinsam erfüllt. Einer von ihnen löst die zuvor beschriebenen regelmäßigen Scans 

aus. Zusätzlich wird für jeden Nachbarn, der eine Verbindung zum BtNAL aufbaut, ein 

Thread erzeugt. Weil Bluetooth-Operationen vergleichsweise hohe Verzögerungen aufweisen 

können, wird auch in Senderichtung bei Bedarf für jeden Nachbarn ein separater 

Thread gestartet. Die dabei aufgebauten OBEX-Sitzungen bleiben so lange wie möglich 

bestehen. 

Der BtNAL enthält keine Maßnahmen zur Sicherung der Bluetooth-Übertragungen vor 

Verlust. Der Schutz wird von den genutzten Protokollen bereits sichergestellt. Da die 

verwendete Programmierschnittstelle keinen Zugriff auf die tatsächlichen Fehlerraten 

gewährt, wird bei allen Bluetoothübertragungen 1 als Wert fü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 Störungen und damit zur Wiederholung von Übertragungen 

kommen kann. 

2 http://bluecove.org/ 

50


Die Fragmentierung die vom Bluetooth-Stack automatisch vorgenommen wird, wird nur 

eingeschränkt benutzt. Damit ein zeitliches Multiplexing von ASP-Kontrollnachrichten 

und Veröffentlichungen ausgeführt werden kann, veranlasst der BtNAL den Broker Nachrichten 

zu fragmentieren. Alle Nachbarn, die über Bluetooth verbunden sind, geben dazu 

eine feste MTU vor. Ohne die Fragmentierung würde der Bluetooth-Stack auch eine mehrere 

Megabyte große Veröffentlichung – für den BtNAL transparent – zu einem Nachbarn 

übertragen. Alle anderen Übertragungen zu diesem Nachbarn müssten jedoch auf das 

Ende der anhaltenden Übertragung warten. Dies würde bei Bluetooth aufgrund der 

verglichen mit Ethernet und WLAN niedrigen Übertragungsraten und den daraus resultierenden 

langen Übertragungszeiten häufig zum Ablauf von Ankündigungen führen. 

4.6. Nachrichtenformat 

Fü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 ergä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 eingeführt. Das erste Byte dient der Identifizierung des Nachrichtentyps. 

Es werden die fü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 Verständnis der Ablä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 Gü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 für die Kosten eine 

Reihe von Bytes ungenutzt. Sie können für zukünftige Erweiterungen genutzt werden. So 

wurde in Abschnitt 3.4.3 bereits angedeutet, dass es bei einer möglichen Erweiterung der 

Metrik notwendig werden könnte, Schätzungen über die Größe von Veröffentlichungen 

in den Ankündigungen zu transportieren. 

Für die Fragmentierung von Veröffentlichungen enthalten Nachrichten vom Typ Publication 

zwei Felder (je vier Byte). In einem ist die Größ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 

über ihre Länge enthalten. Diese Information wird auf Ebene der Broker nicht explizit 

51


benötigt. Dies folgt aus den Anforderungen, dass die Netzwerkabstraktionsschicht Nachrichten 

stets komplett an den Broker ü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 gewählt. Die Auflösung beträgt eine ganze Millisekunde. 

Die zur Berechnung nötigen Angaben werden von dem NAL, den Prozessoranwendungen 

und den Ankündigungen geliefert. Die Kosten sämtlicher eingehender und lokaler 

Ankündigungen sind dem Broker bekannt. Löst ein Prozessor eine Ankündigung aus, 

informiert er den Broker über die ASP IDs, die der Ankündigung zugrunde liegen. Die 

Kosten werden aufsummiert. Daneben gibt der Prozessor die verlangte Schätzung über 

den Bearbeitungsaufwand für das Verarbeiten der Veröffentlichung(en) ab. Die Berechnungsgrundlage 

für die Konverteranwendung wird in Abschnitt 4.2.3 erläutert. Sie wird 

zu den Kosten der neuen Ankündigung addiert. 

Die beiden Implementierungen der Netzwerkabstraktionsschicht liefern die verbleibenden 

Daten (siehe Seite 48 ff.). Dazu gehört die RTT. Sie wird, wie in der Formel 3.3 (S. 43) 

beschrieben ist, in die Kostenberechnung einbezogen. 

Besonders die Parameter S (Größe) und B (Bandbreite) zur Berechnung der ETT (siehe 

Abschnitt 2.7.3) sind mit Blick auf die Implementierung im NAL interessant. Für den 

Parameter S wurde im gesamten System ein fester Wert von 200.000 Byte gewählt. Ein 

Kompromiss, da niedrigere Werte dazu führen können, dass der Faktor S 

B 

gerade bei ho- 

hen 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 ermöglicht. Die Bandbreite B wird über eine Konfigurationsdatei 

vorgegeben. Während der Entwicklung wurde zunächst ein Verfahren implementiert, 

dass die verfügbare Bandbreite sowohl über Bluetooth als auch über UDP misst. Es zeigte 

sich jedoch, dass die Ergebnisse dieser Messungen sehr lastabhängig und außerdem 

plattformabhängig waren. Dies kann im Endeffekt zu Oszillation von Routen führen. Das 

Verfahren wurde aus diesem Grund verworfen. Die fest konfigurierten Werte vermeiden 

das Problem und ermöglichen zusätzliche eine bessere Reproduzierbarkeit der Versuche. 

52

5. Experimenteller Ansatz 


Es wird ein experimenteller Ansatz verfolgt, um die Leistungsfähigkeit von ASP zu beurteilen. 

In Experimenten, die so konzipiert sind, dass sie gezielt relevante Teilaspekte 

von PPS / ASP untersuchen, werden die nötigen Daten gesammelt. Das in Abschnitt 

3.2 beschriebene Szenario und die dort präsentierten Anwendungen bilden die Grundlage 

der Experimente. Diese Experimente und welche Eigenschaften von ASP, mit ihnen 

geprüft werden können, werden im folgenden erläutert. Die Anforderungen, denen die 

Experimente gerecht werden müssen, stehen dabei im Vordergrund. Nur wenn die Rahmenbedingungen 

erfüllt sind, lassen die Experimente Aussagen über das implementierte 

System zu. 

Die Versuche werden mit der in Kapitel 4 vorgestellten Software ausgeführt. Zum besseren 

Verstä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 Erfüllung der aus den Zielen abgeleiteten Hypothesen in einem realen 

System zu überprüfen. Konnte gezeigt werden, dass eines oder mehrere der Ziele 

zufriedenstellend erfü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 Störungen reagiert. 

Die räumliche Entkopplung ist dann gegeben, wenn ein Publisher im Experiment einem 

Subscriber Nachrichten übermitteln kann, ohne dass die einzelnen Akteure wissen, 

wer genau die Nachrichten empfängt bzw. von wo sie stammen. Es wird angenommen, 

dass dies erfüllt ist, wenn Publisher und Subscriber nicht auf direktem Wege Nachrichten 

miteinander austauschen können. Zwischen den beiden Seiten vermittelt allein die ASP- 

Middleware. Direkte Kommunikation ist insbesondere dann nicht möglich, wenn beide 

Seiten unterschiedliche Kommunikationstechniken verwenden, also physisch getrennt 

sind. Verwenden sie kompatible Netzwerktechniken, müssen diese so abgeschottet werden, 

dass der Nachrichtenaustausch auf herkömmlichem Wege nicht mö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). Für die Un- 

53


tersuchung der räumlichen Entkopplung ist kein eigenständiges Experiment vorgesehen, 

denn der Aspekt spielt in jedem der Experimente eine Rolle. 

D 

R 

139.30.216.58/22 

S C 

139.30.3.5/26 

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 geprüft. 

Empfängt ein Subscriber, eine Veröffentlichung, die zu einem Zeitpunkt verbreitet wurde, 

als der Subscriber nicht aktiv oder erreichbar war, ist die zentrale Anforderung erfü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 übernehmen die Rollen Aufzeichnung, Speicherung und Umwandlung (siehe 

Seite 28 ff.). Sie werden zuerst gestartet. Die Rolle Download wird von mehreren weiteren 

Knoten übernommen. Daneben existieren Knoten, auf denen keine Anwendung 

lä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 ausgeführt wird, wenn kein Subscriber aktiv ist, und 

• die Veröffentlichung bei ihrer ersten Verbreitung nicht von allen potenziellen Subscribern 

empfangen werden kann. 

Die semantische Entkopplung ermöglicht Senken durch Einbeziehung von Prozessoren 

Daten zu empfangen, die sie nicht selbstständig verarbeiten können oder möchten. 

Um ihre Funktionsfähigkeit im Szenario zu überprüfen, ist es notwendig mindestens einen 

Prozessor in die Kommunikation zwischen Publisher und Subscriber einzubinden. Das 

Szenario hält dafü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 erfüllen, ist es weiter interessant zu 

betrachten, wie effizient ASP / PPS diese Ziele erreicht. In Abschnitt 2.1 wird ausgeführt, 

54


dass ASP im Kern ein Routingproblem lösen möchte. In einem Experiment ( ” X1“) wird 

ASP daher mit unterschiedlichen Routingalternativen konfrontiert. Dies bedeutet, 

dass mehrere mögliche Routen zwischen Publisher und Subscriber existieren. Dabei wird 

in unterschiedlichen Varianten des Experiments untersucht, wie ASP bei äquivalenten 

Bedingungen reagiert. Die Bandbreite, erreichbare Zuverlässigkeit und Übertragungstechnik 

ausgewählter Verbindungen sind in diesen Experimenten vergleichbar. Da jedoch 

in einem heterogenen Umfeld die Bedingungen häufig variieren, wird zusätzlich das Verhalten 

bei unterschiedlichen Bedingungen untersucht. Diese lassen sich durch Nutzung 

unterschiedlicher Übertragungsraten und Verbindungstechniken herstellen. 

Unterschiedliche Routen können sich auch durch unterschiedlich leistungsfähige 

Prozessoren ergeben. Daher wird in einem weiteren Experiment ( ” X3“) das Verhalten 

des Systems untersucht, wenn entweder gleich leistungsstarke oder unterschiedlich 

leistungsstarke Prozessoren für die Aufgabe der Konvertierung zur Verfügung stehen. 

Dabei ist wichtig, dass sich die Leistungsfähigkeit der Hardware im einen Fall gleicht 

oder im anderen Fall signifikant unterscheidet. 

Ein weiteres Maß mit dem sich die Effizienz von ASP beschreiben lässt, ist die Höhe 

des Verwaltungsaufwands. Die Anzahl der Nachrichten und die Datenmenge, die 

übertragen werden müssen, sind zwei Kenngrößen. Sie werden in einem weiteren Experiment 

( ” X2“) erfasst. Um die Vergleichbarkeit der Messwerte zu gewährleisten, werden 

Werte auf Ebene der Broker gemessen. Alle weiteren Nachrichten, die z.B. zum 

Verbindungsauf- oder -abbau auf Ebene der Netzwerkabstraktionsschicht oder zur Sicherung 

der Übertragung usw. genutzt werden, werden nicht gezä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) berücksichtigt. 

Es wird auch untersucht, wie ASP mit Störungen umgeht. In einer Variante eines der 

Experimente zur Untersuchung der Routen werden einzelne Verbindungen gezielt beeinträchtigt. 

ASP sollte in der Lage sein, seine Aufgabe in der Gegenwart von Störungen 

so gut wie möglich zu erfüllen und zum Beispiel zuverlässige Routen bevorzugen. 

Wie bereits beschrieben wurde, ist für einige Experimente der Einsatz unterschiedlicher 

Verbindungstechniken vorgesehen. Dieses Ziel wird bei der Wahl der Hard- und 

Softwareplattformen für die Experimente berücksichtigt. Jedes Experiment ist ferner 

so angelegt, dass zumindest zwei gä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 können den Abbildungen in Anhang B.3 sowie den Versuchsprotokollen 

entnommen werden. Die Protokolle befinden sich auf dem Datenträ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 Speicherkapazitä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 älteren x86-CPU, USB-WLAN-Adapter und Ethernet. 

Daneben standen drei Linutops zur Verfügung. Es handelt sich dabei um kompakte 

Rechner, die eine x86-CPU und eine Ethernet-Schnittstelle besitzen. Sie verfügen nicht 

ü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 VirtualBox 1 virtualisiert. 

Zur Vernetzung standen ein WLAN-Router (802.11bg) mit eingebautem Ethernet-Switch 

und ein weiterer Switch zur Verfügung. Bei Bedarf wurden die Rechner für einzelne 

Experimente über USB mit WLAN- oder Bluetooth-Adaptern bestückt. 

Die Versuche wurden in einem Wohnumfeld ausgeführt. In der Wohngegend existieren 

viele Funknetze. In einer Messung konnten mit einem Notebook über 20 unterschiedliche 

WLAN-Funkzellen erkannt werden. Daneben konnte gelegentlich die Anwesenheit weiterer 

Bluetooth-Geräte im Umfeld der Versuche registriert werden. Diese waren jedoch 

sehr sporadisch. 

5.2.2. Softwareumfeld 

Es kamen während der Experimente mehrere Betriebssysteme und Java-Laufzeitumgebungen 

zum Einsatz. Genauere Details können der Tabelle B.2 im Anhang entnommen 

werden. 

Während der Experimente kamen die Betriebssysteme Debian, Ubuntu Server und open- 

SUSE Linux sowie Mac OS X und Windows Vista zum Einsatz. Tabelle 5.1 gibt einen 

Ü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 

ähneln dem hier vorgestellten Experiment (Nummer 1, Variante 1, Versuchsreihe 

1 http://www.virtualbox.org/ 

56


Hostname Hardware Betriebssystem 

debian virtuell Debian Linux 

Enif iBook G4 (PPC) Mac OS X 

Hyadum-II x86 Desktop-PC openSUSE Linux 

Kajam x64 Desktop-PC Vista 64 Bit 

linutop (lt) x86 PC Ubuntu Server 

linutop2 (lt2) x86 PC Ubuntu Server 

linutopk (ltk) x86 PC Ubuntu Server 

Tabelle 5.1.: Kurzübersicht der Rechner, die für die Experimente genutzt wurden. Fü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 gewählten Randbedingungen. 

Ziel des Experiments X1v1R2 2 war es, das Verhalten des Systems in der Gegenwart von 

Störungen zu untersuchen. 

An den Versuchen waren fü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 Rolle 

debian Speicherung (S) 

Kajam Konverter (C) 

Enif 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 Störungen zu erzeugen, wurde ein spezielles Skript auf lt bzw. lt2 verwendet. Wird 

es auf einem der beiden Rechner gestartet, deaktiviert es in regelmäßigen Intervallen 

den angeschlossenen WLAN-Adapter. Nach einer Wartezeit wird er wieder aktiviert. 

2 Gemeint ist Experiment 1, Variante 1, Reihe 2. Die verwendeten Kürzel zur Bezeichnung von Experimenten 

und Versuchen werden auf Seite 77 näher beschrieben. 

57


Die Dauer der beiden Phasen ” WLAN an“ und ” WLAN aus“ konnten getrennt definiert 

werden. Es wird darauf hingewiesen, dass die so erzeugten Störungen synthetisch 

sind. Außerhalb der Versuchsumgebung sind andere Störungen zu erwarten. Für die 

Experimente hatte dieses Vorgehen jedoch den entscheidenden Vorteil, dass die Versuche 

leichter zu wiederholen waren. Zudem konnten die Störungen erzeugt werden, ohne 

zusätzliche Geräte einzusetzen. Diese hätten möglicherweise unbeteiligte Nutzer in der 

Umgebung beeinträchtigen können. 

Die Versuche liefen so ab, dass zunächst das Skript gestartet wurde, welches in regelmäßigen 

Intervallen das WLAN stö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 für die 

Stö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 künstlichen Störungen wiederholt. 

58

6. Auswertung 

6. Auswertung 

In den folgenden Abschnitten werden die Ergebnisse der Experimente beleuchtet. Tabelle 

B.1 (S. 78) gibt eine Übersicht der durchgeführten Versuche. Die Versuche sind unterteilt 

nach Experiment, Variante und Versuchsreihe. Die Versuche eines Experiments haben 

einen ähnlichen Ablauf und eine gemeinsame Zielstellung. Die Versuche verschiedener 

Varianten eines Experiments unterscheiden sich geringfügig im Messaufbau, wie z.B. 

Verteilung der Rollen und der Art der Verbindungen zwischen Nachbarn. Bestimmte 

Abkürzungen werden verwendet, um einzelne oder mehrere Versuche zu bezeichnen. 

Eine ausführliche Erklä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 Datenträ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 räumlich entkoppelt und 

3. erfolgt auf Grundlage von Nachbarschaftsbeziehungen. 

4. Das System arbeitet mit einem niedrigen Verwaltungsaufwand. 

5. Die zeitliche Entkopplung der Kommunikation ist gewährleistet. 

6. Unter den alternativen Übertragungswegen wird ein effizienter gewählt. 

7. Gestörte Übertragungswege werden vermieden und 

8. unterschiedliche Übertragungstechnologien können genutzt werden. 

9. Für die Datenverarbeitung werden die leistungsfähigsten der verfügbaren Geräte 

eingebunden. 

Welche Versuche vordergründig genutzt wurden, um die einzelnen Hypothesen zu untersuchen, 

gibt Tabelle 6.1 wieder. Bei der Auswertung werden Versuchsergebnisse, die 

mit den Erwartungen übereinstimmen, zusammengefasst. Alle Fälle, in denen die Ergebnisse 

von den Erwartungen abwichen, werden anhand der vorliegenden Daten genauer 

untersucht. 

59

6. Auswertung 

Untersuchungsaspekt Versuche 

Heterogenität alle 

Räumliche Entkopplung alle 

Nachbarschaftsbeziehungen alle, außer X3 

Verwaltungsaufwand X2 

Zeitliche Entkopplung X5R2 

Alternative Übertragungswege X1v1, X1v2 

Gestörte Übertragungswege X1v1R2 

Alternative Übertragungstechniken X1v2 

Alternative Prozessoren X3 

Tabelle 6.1.: Die untersuchten Aspekte und die Versuche, die genutzt wurden, um Aussagen 

über die Aspekte zu treffen. Siehe Tab. B.1. 

6.1. Heterogenität 

ASP wurde für den Einsatz in heterogenen Netzen konzipiert. Dieses Ziel wurde bei der 

Implementierung berücksichtigt. Die in Abschnitt 5.1 eingeführten Experimente sind 

so angelegt, dass sie eine heterogene Umgebung zugrunde legen. Für die Durchführung 

der Experimente standen sehr unterschiedliche Rechner zur Verfügung. Damit sind die 

Voraussetzungen erfüllt, um ASP in einem heterogenen Umfeld zu testen. 

Es wird angenommen, dass die Implementierung von ASP in dem gegebenen Testumfeld 

auf allen verfügbaren Plattformen und mit unterschiedlichen Netzwerktechniken 

funktioniert. Diese Hypothese konnte in den praktischen Versuchen bestätigt werden. 

Bei den Experimenten kamen in Summe sieben verschiedene Rechner zum Einsatz, die 

fünf verschiedene Hard- bzw. Softwareplattformen einsetzten. Für die Kommunikation 

wurden die Technologien WLAN, Ethernet und Bluetooth verwendet, wobei unterschiedliche 

Hardware zum Einsatz kam. In sämtlichen Versuchen konnten die ASP-Middleware 

und die darauf aufbauenden Anwendungen ausgeführt werden. Die Middleware hat stets 

Nachrichten mit mindestens einem benachbarten Broker austauschen können. 

Lediglich ein einziger Rechner (linutop2) konnte bei einem der Versuche keine Nachrichten 

austauschen (X5R2/X5O). Die Ursache für dieses Verhalten konnte anhand der 

Logdateien nicht geklärt werden. Aus ihnen geht jedoch hervor, dass die Kommunikation 

nur teilweise eingeschränkt war. Der einzige Nachbar (Hyadum-II), mit dem linutop2 

zum Zeitpunkt des Versuchs kommunizieren konnte, hat linutop2 als Nachbarn registriert. 

Das lässt darauf schließen, dass Übertragungen in eine Richtung funktionierten. 

6.2. Räumliche Entkopplung 

Das Ziel der räumlichen Entkopplung wurde bei der Gestaltung der Anwendungsschnittstelle 

berücksichtigt. Keine Quelle kann eine Nachricht veröffentlichen und dabei einen 

60

6. Auswertung 

oder mehrere Empfänger spezifizieren. Auf der anderen Seite erfährt keine Senke je den 

Absender einer Veröffentlichung. Werden diese Schnittstellen im Experiment erfolgreich 

eingesetzt um Veröffentlichungen zu verbreiten, wird angenommen, dass räumliche Entkopplung 

vorliegt. 

In jedem der durchgeführten Experimente nutzten die Anwendungen die ihnen gegebenen 

Schnittstellen um mit anderen Anwendungen zu kommunizieren – unabhängig davon, 

auf welchem Knoten diese aktiv waren. Mit der auf Grundlage von ASP implementierten 

Middleware ist es demnach möglich, dass Anwendungen mittels Publish/Subscribe 

räumlich entkoppelt Daten austauschen kö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 Verfügung stehenden Netzwerkschnittstellen 

Daten austauschen kö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 durchgefü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 

Verfügung stehen. Die Kommunikation ü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 kö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 Veröffentlichungen zu 

verbreiten und zu empfangen. 

Der erfolgreiche Nachrichtenaustausch lässt sich zum Beispiel an den Ergebnissen von 

Experiment X1v2R1 nachvollziehen. Bei dem Experiment hatte der Rechner linutop2, 

an dem der Download ausgeführt wurde, zwei Verbindungen zum Rest des Netzwerks 

(siehe Skizze auf Seite 80). Eine Verbindung bestand über ein Ad-Hoc-WLAN, die andere 

über Bluetooth. In jedem der Versuche konnte der Anwendung der Download, also die 

transparent verarbeitete Verö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 

Ankündigungen verbreitet. Tabelle 6.2 illustriert dies anhand einiger Zahlen. Die Werte 

geben wieder, wie viele Ankündigungen im Verlauf der Versuche beim Knoten linutop2 

eingingen. Alle Ankündigungen wurden ursprünglich von Brokern versandt, mit denen 

der Broker auf linutop2 nicht direkt kommunizieren kann. 

Versuch A B C D E F G H I J K L 

Ank. S 11 13 14 13 8 14 13 13 14 11 13 13 

Ank. C 9 11 11 11 6 11 10 11 11 9 11 11 

Tabelle 6.2.: Anzahl der in Experiment 1, Variante 2, Reihe 1 bei linutop2 eingegangenen 

Ankündigungen der gespeicherten Aufzeichnung (Ank. S) und der konvertierten 

Aufzeichnung (Ank. C). 

6.4. Verwaltungsaufwand 

Experiment 2 wurde speziell durchgeführt um den Verwaltungsaufwand zu ermitteln, den 

die ASP-Implementierung verursacht, um ihre Aufgaben zu erfüllen. Bevor detailliert auf 

die Ergebnisse eingegangen wird, wird erläutert, wie die Datenmengen gezählt wurden 

und wie der Verwaltungsaufwand berechnet wurde. 

Die Erfassung der Datenmengen folgte dem in Abschnitt 5.1 vorgestellten Ansatz für 

Experiment 2. Es wurden grundsätzlich nur die Nachrichten und ihr Umfang auf Ebene 

der Broker erfasst. Bei der weiteren Berechnung wurden alle übertragenen Daten 

außer der Nutzlast, die mit Veröffentlichungen transportiert wurde, als Verwaltungsdaten 

betrachtet. Das bedeutet, dass insbesondere Ankündigungen, Abonnements, deren 

Kündigungen usw. zu 100 % als Verwaltungsdaten betrachtet wurden. 

Um die Effizienz der Implementierung zu bestimmen, wurde zunä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 Übertragung der Aufzeichnung zum 

Speicher zu vereinzelten Verlusten von Veröffentlichungen. Die Gründe dafür werden 

an anderer Stelle diskutiert. Verlust bei der Übertragung der Audiomitschnitte bedeutet, 

dass die Datei, die in das Archiv geschrieben wird, gegenüber einem vollständig 

übertragenen Mitschnitt entsprechend kleiner ist. Dadurch ändert sich auch der Umfang 

der Daten, die an den Prozessor weitergegeben werden. Und auch die komprimierte 

Audiodatei hat eine andere Größe, wenn sich die Ausgangsdaten ändern. 

Die Vorgehensweise lässt sich an zwei Beispielen verdeutlichen. Bei Versuch X2R2/X2A 

kam es nicht zum Verlust von Veröffentlichungen. Es wurden also alle 1105 Veröffentlichungen 

(1.413.166 Byte Audiodaten) vom Rekorder übertragen und der Speicheranwendung 

zugestellt. Zum Konverter wurden 1.413.210 Byte 1 übertragen. Die komprimierte 

Audiodatei hat eine Größe von 255515 Byte. In Summe sind dies 1413166 + 1413210 + 

1 1.413.166 Byte + 44 Byte zusätzlicher Dateikopf 

62

6. Auswertung 

255515 = 3081891 Byte. Bei Versuch X2R2/X2L kam es zum Verlust einer Verö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 Übertragungen von Nutzdaten ebenfalls 

als Verwaltungsaufwand gewertet werden. Unter idealen Bedingungen sollte jede Veröffentlichung 

nur so oft wie nötig übertragen werden. 

Die Gültigkeit von Ankündigungen hat einen Einfluss auf das von der Middleware generierte 

Datenvolumen. Haben Ankündigungen eine kurze Gültigkeit, werden sie häufig 

verlängert und es werden entsprechend mehr Ankündigungen im Netzwerk verbreitet. 

Für alle Versuche zu Experiment 2 wurden folgende Werte gewählt: 

• Rekorder: 4.000 ms 

• Speicher: 20.000 ms 

• Konverter: 10.000 ms 

Für die Ankündigungen des Rekorders wurden 4 Sekunden gewählt, damit bei Bedarf 

besonders schnell auf Störungen auf dem Ü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 ausgeführt, die noch unvollständig war und einige kleinere Fehler 

enthielt. Allerdings sind die vorläufigen Zahlen, die sich aus der Auswertung von X2R1 

ergaben, durchaus mit denen von X2R2 vergleichbar. 

Der Ablauf der Versuche war folgender: Zunä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 ü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 fä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 für das Absinken 

der Effizienz sind redundate Übertragungen von Veröffentlichungen des Rekorders. 

Diese Redundanz wurde durch Änderungen der Routen ausgelöst. Nach dem der neue 

63

6. Auswertung 

Pfad mit einem Abonnement aktiviert wurde, wurden bisher erzeugte Veröffentlichungen 

aus dem Cache des Publishers übertragen. Abhängig vom Zeitpunkt der Routenänderungen 

hatte sich der Cache für Veröffentlichungen bereits unterschiedlich stark 

gefüllt. 

Die niedrige Effizienz in Versuch X2R2/X2P kann nicht auf dieselbe Weise erklärt werden. 

Es kam zu einer doppelten Übertragung der gespeicherten Aufzeichnung zum Konverter. 

Sie war des Ergebnis einer nicht abgefangenen Race Condition. Es kam zu einer 

zeitlichen Überschneidung von drei Ereignissen. Zunächst empfing der Konverter eine 

Folgeankündigung des gespeicherten Mitschnitts (1). Zu diesem Zeitpunkt hatte der 

Konverter Interesse an der Veröffentlichung und hatte diese bereits abonniert. Nur circa 

90 ms nach dem Eintreffen der Ankündigung verschickte der Konverter die Kündigung 

des Inhalts (2). Das verzögerte Abonnement, welches durch die Folgeankündigung ausgelöst 

wurde, wurde etwa 20 ms nach der Kündigung verschickt (3). 

6.5. Zeitliche Entkopplung 

Mit Experiment 5 diente das aufwändigste aller durchgefü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 

gänzlich außen vor. Bei diesem Versuch kam es zu einem Bedienfehler. Im Gegenzug 

wurde ein Versuch mehr durchgeführt, als ursprü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 Veröffentlichungen 

unter bestimmten Randbedingungen empfangen können. Diese Randbedingungen 

umfassen, dass der oder die Subscriber während der Ausfü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 lässt den Schluss zu, dass das implementierte 

System die zeitliche Entkopplung korrekt umsetzt. 

Die Aussage wird ebenfalls durch X5R1 untermauert. Allerdings müssen Einschränkungen 

gemacht werden. Der zweite Download konnte in einigen Fä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 

Veröffentlichung auf der Verbindung zu dem zweiten Rechner (linutop2) wiederholt werden. 

Aufgrund eines Softwarefehlers schlug die Wiederholung fehl. Dieser Fehler wurde 

bis zur Ausführung der Versuche X5R2 korrigiert. Die Situation in Versuch X5R1/X5O 

wurden bereits in Abschnitt 6.1 beschrieben. 

64

6. Auswertung 

100 % 

5000000 

4500000 

95 % 

4000000 

90 % 

3500000 

85 % 

3000000 

Effizienz 

80 % 

2500000 

Datenmenge [Bytes] 

2000000 

75 % 

1500000 

70 % 

1000000 

65 % 

500000 

60 % 

A B C D E F G H I J K L M N O P Q R S T 

Versuch 

Abbildung 6.1.: Der Verwaltungsaufwand in Experiment 2, Reihe 2. 

0 

gespeicherte Aufnahme (Nutzdaten) 

konvertierte Aufnahme (Nutzdaten) 

Effizienz (netto Soll : brutto Ist) 

Summe aller Daten (inkl. Kontrollnachrichten) 

Aufnahme (Nutzdaten) 

65

6. Auswertung 

Es wurde weiterhin beobachtet, dass sich die Reaktionszeiten des Systems durch das 

Caching von Veröffentlichungen verbessern. Der Konverter konnte sämtliche Publikationen, 

die von linutop2 abonniert wurden, aus dem Cache zustellen. Im Cache lag die 

Veröffentlichung bereits vor, weil linutop diese zuvor abonniert hatte. Die gespeicherte 

Aufnahme wurde daraufhin abonniert, übertragen, konvertiert, im Cache abgelegt und 

an die Downloadanwendung auf linutop übertragen. In Abbildung 6.2 werden die Zeiten 

zwischen Versand des Abonnements und dem Eingang der Veröffentlichung verglichen. 

Zeit [ms] 

12000 

10000 

8000 

6000 

4000 

2000 

0 

A B C D E F G H I J L M N O P Q R S T U 

Versuch 

Download auf linutop 

Download auf linutop2 

Abbildung 6.2.: Ein Vergleich der Downloadzeiten der konvertierten Audioaufnahme aus 

X5R2. Durch den Einsatz des Caches für Veröffentlichungen konnte die 

Übertragungszeit beim zweiten Download deutlich reduziert werden. 

6.6. Alternative Übertragungswege 

Das Routing von Nachrichten ist eine der Kernaufgaben von ASP. Um die (korrekte) 

Funktionsweise des Routings zu ermitteln, wurde eine Vielzahl von Versuchen durchgefü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 gegenüberstellen. 

Die Experimente X1v1 und X1v2 untersuchen, ob das implementierte System Nachrichten 

korrekt und effizient transportiert. In X1v1R1 wurden Übertragungswege mit 

unterschiedlichen Bandbreiten gegenübergestellt. X1v1R2 wurde durchgeführt, um das 

Routing in Gegenwart von Störungen zu überprüfen. Die Middleware musste in X1v2R1 

zwischen den beiden unterschiedlichen Netzwerktechniken WLAN und Bluetooth (siehe 

Abschnitt 2.8.3 und 2.8.4) wählen. 

Die Netzwerktopologie in den Versuchen X1v1R1 war so angelegt, dass der Download der 

konvertierten Audiodatei über eine von zwei möglichen Verbindungen übertragen wer- 

66

6. Auswertung 

den musste. Beides waren WLAN-Verbindungen nach 802.11bg. Eine der beiden Verbindungen 

wurde während der Versuche mit einer festen Bitrate von 1 MBit/s, 11 MBit/s, 

54 MBit/s oder mit automatischer Bitratenwahl betrieben, die andere durchgängig mit 

automatischer Bitratenwahl. Durchsatzmessungen im Vorfeld der Versuche ergaben, dass 

sich die erzielten Nettodatenraten bei 54 MBit/s nur geringfü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 zunächst die Ergebnisse bei 1 und 11 MBit/s interessant. 

Es wurde eine Auswertung der Kosten vorgenommen, die die Metrik für Ankündigungen 

ermittelte, die bei dem Computer eingingen, auf dem der Download ausgeführt 

wurde. Die durchschnittlichen Kosten der beiden alternativen Verbindungen wurden verglichen. 

Erwartungsgemäß sollte die Verö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 Veröffentlichung kam. In allen anderen 

Versuchen von X1R1 wurde die Veröffentlichung zugestellt. 

Bei 1 MBit/s wä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 Ausnahmefällen die vermeintlich langsamere Verbindung für die Übertragung 

genutzt wurde. Der häufigere Grund war, dass Ankündigungen entlang der besseren 

Verbindung (vorübergehend) überhaupt nicht oder zu spät eintrafen. Daraufhin wurde 

die Route geändert und für den Rest des Versuchs beibehalten. Der andere Grund war, 

dass eine der Verbindungen überhaupt nicht zustande kam oder in einer frü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 gewählt. 

Tabelle 6.3 fasst die ermittelten durchschnittlichen Kosten über alle Versuche X1R1 zusammen. 

Es sind die Kosten der Pfade vom Speicher (Quelle) zum Download (Senke) 

unter Einbeziehung des Konverters (Prozessor). Genauere Angaben können den Abbildungen 

B.6 bis B.9 im Anhang B.5 entnommen werden. 

Aus der Tabelle geht hervor, dass sich die ü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 überraschender ist es, 

dass sich zum Beispiel bei den Versuchen mit 54 MBit/s in 10 von 12 Fällen die Route 

ü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 über linutop im 

Durchschnitt geringfügig besser eingeschätzt wurde. 

Um die Ursache dieser Beobachtung zu klären, wurde für sämtliche Versuche aus X1R1 

zusätzlich der Wert des Feldes TTL aus dem Nachrichtenkopf der Ankündigungen ausgewertet. 

Die Versuche bei 1 MBit/s und 11 MBit/s werden im folgenden nicht weiter 

berücksichtigt, da sich die Kosten der beiden alternativen Routen erwartungsgemäß stark 

unterscheiden. Mit Hilfe der TTL kann nachvollzogen werden, ü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 Fällen 

dann geringer, wenn auch die Ankündigungen im Durchschnitt über weniger Knoten weitergeleitet 

wurden. Bei automatischer Bitratenwahl ist das Verhältnis 13 aus 17, wenn 

man die Versuche unberücksichtigt lässt, in denen über linutop gar keine Ankündigungen 

empfangen wurden. Tabelle 6.3 gibt die durchschnittliche Anzahl der Hops aller Ankündigungen 

des Downloads wieder. Es werden nur die Ankündigungen berücksichtigt, die 

bei Enif eingingen. 

Bitrate Kosten Hops Kosten Hops 

bei linutop2 via linutop via linutop2 

1 MBit/s 2900,31 2,6 6363,26 2,5 

11 MBit/s 2813,26 2,4 3228,32 2,6 

54 MBit/s 2752,62 2,3 2752,66 2,6 

auto 2739,08 2,3 2753,04 2,7 

Tabelle 6.3.: Die durchschnittliche Kosten für die Ü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 Ankündigungen 

auf dem Weg zur Downloadanwendungen zurückgelegt haben. 

Es wird vermutet, dass die Art und Weise mit der Ankündigungen im Netzwerk geflutet 

werden, die Hauptursache für die Unterschiede der Kosten der ansonsten nahezu 

gleichwertigen Pfade ist. Jeder Broker leitet eine eingehende Ankündigung an alle Nachbarn 

mit Ausnahme des Absenders weiter. Eine einmal erhaltene Ankü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 Ankündigung, die b4 erhält, hat bereits drei Hops 

zurückgelegt. Angenommen alle Verbindungen sind äquivalent in Bezug auf Bandbreite 

und Latenz. Unter diesen Umständen hat die Metrik für die Ankündigung, die bei b4 zuerst 

eingeht, bereits höhere Kosten ermittelt als sie sie für die Übertragung von b1 zu b4 

ermittelt. Im Ergebnis haben die Ankündigungen, die einen längeren Weg zurückgelegt 

haben höhere Kosten. 

Es wurden bereits Vorschläge gemacht, wie die Verbreitung von Ankündigungen weiter 

optimiert werden kann [Ris09b]. Zusätzliche Optimierungen sind notwendig, damit sich 

die Ankündigungen mit den niedrigsten Kosten ausbreiten und nicht jene, die lediglich 

am schnellsten weitergeleitet werden. 

Ein weiterer Erklärungsansatz ist, dass die Übertragungseigenschaften der Funkstrecke 

zwischen linutop und Enif während der Versuche besser waren, als zwischen linutop2 

und Enif. Anhand der vorliegenden Zahlen, kann darüber jedoch keine Aussage gemacht 

werden. Die Versuche sind ungeeignet, die genauen (physikalischen) Übertragungseigenschaften 

der Verbindungen zu ermitteln. 

68

6. Auswertung 

b2 

1. 

b1 

2. 

5. 

3. 4. 

Abbildung 6.3.: Der Broker b1 verschickt eine Ankündigung. Gezeigt werden die ersten 

fünf Schritte einer möglichen zeitlichen Abfolge bei der Verbreitung der 

Nachrichten. 

Obwohl die Routen über linutop häufig bevorzugt wurden, waren sie bei 54 MBit/s im 

Durchschnitt nicht immer die günstigeren. Eine genauere Untersuchung der Versuche 

X1R1@54M/X1C, /X1F, /X1G, /X1I und /X1L ergab, dass die gewählte Route unmittelbar 

vor Aktivierung eines Pfades die attraktivere war. Die Kosten der Routen ü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. 

Für das Routing in Gegenwart von unterschiedlich leistungsfähigen Verbindungen wird 

festgehalten, dass die vorhandene Implementierung zuverlässig geeignete Routen wählt. 

Nachrichten werden auf den besten verfügbaren Verbindungen übertragen. Sind zwei alternative 

Routen (nahezu) äquivalent, bevorzugte das System jedoch bestimmte Routen. 

Es ist vorstellbar, dass dies in größeren Szenarien und bei höherem Datenaufkommen zu 

Überlastung einzelner Verbindungen führen kann. 

6.7. Gestörte Übertragungswege 

In den Versuchen X1v1R2 wurde untersucht, wie sich das System verhält, wenn neben 

einer intakten Route eine zweite, gestörte Route existiert. Im Laufe eines Versuchs musste 

die Middleware eine der beiden Routen zur Ü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 ausgeführt wurde und dem Rest 

des Netzwerks wurde nicht gestört. Die andere Verbindung wurde gezielt gestört. In regelmäßigen 

Intervallen wurde die Verbindung kurzzeitig deaktiviert. Die Versuche wurden 

so ausgeführt, dass die gestörte Verbindung 80 % der Zeit, 90 % und zum Vergleich 

auch 100 % der Zeit aktiv und damit ungestört war. Die Rollen der gestörten und ungestörten 

Verbindung wurden getauscht. Bei den insgesamt 59 ausgeführten Versuchen 

b3 

b4 

69

6. Auswertung 

dieses Experiments konnte der konvertierte Audiomitschnitt dreimal nicht erfolgreich 

zugestellt werden. Jeder dieser Verluste von Veröffentlichungen trat in Versuchen auf, 

bei denen die gezielten Störungen am stärksten waren. 

Wie beispielsweise dem Diagramm in Abb. B.10 (im Anhang) gut zu entnehmen ist, 

spricht die Metrik gut auf die gestörten Verbindungen an. Das bedeutet, dass die Kosten 

entlang der gestörten Verbindung höher sind als die Kosten, die für die Übertragung über 

die ungestörte Verbindung ermittelt wurden. Zum Vergleich zeigt Abb. B.11 die gemessenen 

Kosten derselben Anordnung ohne die künstlichen Störungen. Da die Messungen 

der Verlustrate periodisch ausgeführt werden, ist es möglich, dass nicht jede Störung erkannt 

wird. Tritt eine der Auszeiten zwischen zwei Messungen auf und finden in diesem 

Zeitraum keine anderen Übertragungen statt, ist die implementierte Middleware nicht 

in der Lage, die Störung zu erkennen. 

In 54 von 59 Versuchen (92 %) hat die Middleware für die Übertragung diejenige Verbindung 

gewählt, die durchschnittlich die niedrigeren Kosten aufwies. Bei fünf Übertragungen 

wurde die gestörte Verbindung ausgewählt. Jede dieser fünf gestörten Routen 

wurde zum Zeitpunkt der Aktivierung des Pfades als die bessere eingeschätzt. Das bedeutet, 

dass die Störungen bis zu diesem Zeitpunkt nicht erkannt worden sind. Da die 

durchschnittlich für diese Verbindungen ermittelten Kosten jedoch über denen der ungestörten 

Verbindungen lagen, bedeutet dies, dass die Stö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 Störungen auf andere, ungestörte Routen 

auszuweichen. 

6.8. Alternative Übertragungstechniken 

In einer Variante des Experiments 1 wurde erneut der Rechner, auf dem der Download 

der Aufzeichnung stattfinden sollte, über zwei Verbindungen mit dem Rest des Netzwerks 

verbunden. Eine Verbindung wurde über WLAN hergestellt, die andere mittels 

Bluetooth. 

In jedem der Versuche konnte die Veröffentlichung übertragen werden. Einmal wurde 

dafür die Verbindung über Bluetooth genutzt. In allen anderen Fällen wurde die WLAN- 

Verbindung genutzt. Das deckt sich mit den Erwartungen. Die WLAN-Verbindung hat 

eine höhere Bandbreite. In vorbereitenden Tests wies sie zudem eine geringere Übertragungslatenz 

auf. Im Versuch X1v2R1/X1E, bei dem die Veröffentlichung über Bluetooth 

übertragen wurde, riss die WLAN-Verbindung ab und konnte bis zum Ende des Versuchs 

nicht wieder aufgebaut werden. Über die WLAN-Verbindung konnte bis zum Ausfall 

nur eine einzige Ankündigung des konvertierten Audiomitschnitts übertragen werden. 

Danach wurden keine weiteren Ankündigungen mehr auf diesem Wege zugestellt. Die 

Route über die Bluetooth-Verbindung war somit zum Zeitpunkt des Abonnements der 

einzige verfügbare Weg. 

70

6. Auswertung 

Eine weitere Beobachtung wurde bei der Auswertung der Zahlen aus X1v2R1 gemacht. 

Insbesondere zu Beginn der Versuche, also noch während der Wartezeit bevor das Abonnement 

des Audiomitschnitts ausgelöst wurde, traten entlang der WLAN-Verbindung 

häufige Verbindungsverluste auf. Dies führte dazu, dass die von der Metrik ermittelten 

durchschnittlichen Kosten für die Route entlang der WLAN-Verbindung von Versuch zu 

Versuch deutlich schwanken. 

Eine erste Vermutung dazu war, dass die Bluetooth-Übertragungen bzw. die Übertragungsversuche 

die WLAN-Verbindung beeinträchtigen würden. Dazu wurde ein getrenntes 

Experiment durchgefü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-Aktivitäten und der WLAN-Verbindung 

gab. Diese Vermutung konnte deutlich bestätigt werden. Im Experiment sendete ein Linutop 

über ein Ad-Hoc-WLAN regelmäßig ICMP-Echo-Requests (ping; siehe [Pos81]) 

an einen zweiten Linutop, der zusätzlich mit einem Bluetooth-Adapter ausgestattet war. 

Auf dem zweiten Gerät wurde ein Skript aktiviert, dass in regelmäßigen Abständen zwanzig 

Inquiry Scans ausführte. Im Protokoll der ICMP-Antwortzeiten sind diese Scans klar 

wiederzuerkennen (siehe Grafik 6.4). Die genauen Umstände dieser Wechselwirkungen 

wurden nicht untersucht. Für die Versuche aus X1v2R1 war es ausreichend zu wissen, 

dass eine solche negative Wirkung von Bluetooth auf die WLAN-Verbindung existierte. 

Zeit [ms] 

25 

20 

15 

10 

5 

0 

0 100 200 300 400 500 

ICMP Sequenznummer 

ICMP Echo Antwortzeit 

Abbildung 6.4.: Bluetooth Inquiry Scans stören in der Versuchsumgebung den Datenaustausch 

über WLAN – erkennbar an den 20 ausgeprägten Lücken. 

Als Ergebnis des Experiments X1v2R2 wird festgehalten, dass die implementierte Middleware 

korrekt zwischen den verfügbaren Übertragungstechniken wählt. Die leistungsfähigste 

Technik kommt zum Einsatz und die Metrik bildet die Grundlage dieser Entscheidung. 

Im Übrigen ist die Übertragungstechnik für die Anwendungen, die die Middleware 

nutzen, transparent. 

6.9. Alternative Prozessoren 

Die Versuche zu Experiment 2 beschäftigten sich ausfü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 Verfügung 

stehen. Die Rolle des Konverters, wie sie im Szenario auftritt (siehe Abschnitt 3.3.1) 

wird dabei von mehr als nur einer Anwendung übernommen. Die Anwendungen werden 

auf unterschiedlichen Computern ausgeführt, die je nach Variante über unterschiedlich 

oder gleich leistungsfähige Hardware verfügen. 

Damit allein die Leistungsfähigkeit der Prozessoren über die Wahl der Route entscheidet, 

wurde der Einfluss der Netzwerkanbindung in den Versuchen so weit wie mö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 

über alle Versuche gesehen zwischen beiden Linutops gleichverteilt ist. Die Auswertung 

hat jedoch ein Verhältnis von ungefähr 2:1 zu Gunsten von linutop1 ergeben. Das heißt, 

linutop1 hat bei zwei Dritteln der Versuche die Konvertierung übernommen. Der Versuchsablauf 

wurde daraufhin leicht abgewandelt, um die Diskrepanz von Erwartung und 

beobachtetem Ergebnis aufzuklären. Bei Reihe 1 wurden die beiden Prozessoren unmittelbar 

nacheinander mit einer geringen Verzö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. 

Für den leistungsstärkeren wurde beim Umwandeln einer Referenzaudiodatei ein Geschwindigkeitsfaktor 

von 6,3 ermittelt und für den schwächeren 0,9. Gleichzeitig sind 

dies die Zahlen, die der jeweiligen Konverteranwendung als Berechnungsgrundlage für 

die Abschä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 früher gestartet wurde. Dies galt auch dann, wenn der leistungsschwächere 

zuerst gestartet wurde. 

Die Ursache dieses Effekts konnte anhand der erfassten Protokolle gefunden werden. 

Sie kann jedoch auch unabhängig davon theoretisch mit der Funktionsweise der implementierten 

Middleware begründet werden. Die Verlängerung von Ankündigungen ist ein 

Mechanismus, der vorgesehen ist, um aktive Pfade aufrechtzuerhalten. Verlängert ein 

Broker die Gültigkeit einer Ankündigung mit einer Folgeankündigung, mü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 abgestürzt ist, wird der Pfad verworfen. Folgeankündigungen 

können von Duplikaten oder alten Ankündigungen an ihrer fortlaufenden Sequenznummer 

im Kopf der Nachrichten unterschieden werden. Kündigen mehrere Prozessoren 

Veröffentlichungen derselben ASP ID an, und verlängern sie ihre Ankündigungen im selben 

Intervall – was bei den Versuchen der Fall war – setzen sich die Ankündigungen des 

Prozessors bzw. seines Brokers durch, der die höchsten Sequenznummern verwendet. Das 

ist in der Regel der Broker, der am längsten aktiv ist. Verwendet einer der Prozessoren 

ein kürzeres Intervall, wird er sich auf Dauer auch dann durchsetzen, wenn er nicht seit 

längstem aktiv ist. 

Die Versuche zeigen, dass dieses Fehlverhalten in der angefertigten Implementierung 

auftritt. Das vorliegende System eignet sich deshalb nur unter Einschränkungen fü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 grundsätzliches Problem. Das Verhalten eines ASP-Systems unter diesen Umständen 

wurde bislang weder ausgeschlossen, noch spezifiziert. Da es grundsätzlich gewünscht ist, 

dass mehrere alternative Prozessoren zum Verarbeiten einer Verö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

7. Schlussbetrachtungen 


In diesem Kapitel wird die Arbeit zunächst zusammengefasst. In einem weiteren Abschnitt 

wird ein Ausblick auf mögliche zukü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 

ermöglicht. 

Erstmals wurde auf Grundlage von ASP eine Kommunikationsmiddleware für den Einsatz 

in einem realen Umfeld implementiert. Offene Fragen des Ansatzes, die im Vorfeld 

der Implementierung zu klären waren, wurden erläutert. In einem sehr heterogenen 

Umfeld ist das Szenario angesiedelt, in dem das implementierte System geprü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 ü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 erfüllen. Das entwickelte System konnte 

erfolgreich die rä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 grundsätzlich. Für die Datenverarbeitung wurde 

lediglich nicht immer das leistungsfähigste Gerät ausgewählt. Dieser Fall wurde bislang 

noch nicht vollstä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 Störungen, wie sie in den Versuchen erzeugt wurden, konnte das 

System gut umgehen. 

74


7.2. Ausblick 

Es existieren unterschiedliche Ansätze das Konzept von ASP zu erweitern und weiter 

zu optimieren. Es ist vielversprechend, besonders die Verbreitung von Ankündigungen 

und die genauere Ermittlung aller Pfade und ihrer Kosten gegenüber dem verwendeten 

Prototyp weiter auszubauen. Wegen der vielen Möglichkeiten, diese Aufgabe zu lösen, 

empfehlen sich Simulationen, um die erfolgversprechendsten Ansätze zu identifizieren. 

Die gefundenen Ansätze können dann in einem nächsten Schritt in der Praxis erprobt 

werden. 

Während der Entwicklung der Software und der Durchführung der Tests, stellte sich 

die wichtige Rolle des Caching heraus. In den Versuchen wurde eine einfache Caching- 

Strategie 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 Übertragungen sollten 

sich weiter reduzieren lassen. 

Mit Blick auf Dienstgütemerkmale wie die Latenz oder den Verlust von Nachrichten kann 

den existierenden Übertragungskategorien in Zukunft eine wichtigere Rolle zukommen. 

Die Möglichkeit die gewünschte Dienstgüte flexibel zu konfigurieren, kann dem Konzept 

von ASP weitere Anwendungsbereiche erschließen. 

Zu den Untersuchungsaspekten, die bislang nicht berücksichtigt werden konnten, gehört 

die Evaluation größ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 unterstützt die erstellte 

Software jedoch bereits grundsätzlich Verbindungstechniken, die sich fü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 Endgeräten zum Einsatz zu bringen. Auch weitere 

Übertragungstechnologien wie das bereits eingangs genannte ZigBee können in Zukunft 

erschlossen werden. Auf diese Weise lässt sich prüfen, ob ASP für den Einsatz in Sensornetzen 

angepasst werden kann. 

75

A. Nachrichtenformat 

A. Nachrichtenformat 

Nachrichtentyp Feldgröße in Byte und -bedeutung 

COMMON 

� 

TYPE 

TTL 

2 1 1 

ANNOUNCEMENT ID 

SUBSCRIPTION, 

UNSUBSCRIPTION, 

BROKENPATH 

METRIC 

VALIDITY 

SEQUENCE 

PAYLOAD 

≥ 33 1 1 16 8 4 2 ≥ 1 

ID 

SUBSCRIBERID 

METRIC 

34 1 1 16 8 8 

PUBLICATION ID 

SEQUENCE 

PAYLOADSIZE 

OFFSET 

PAYLOAD 

≥ 29 1 1 16 2 4 4 ≥ 1 

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 Datenträ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 Kürzel, mit denen Versuche bezeichnet werden, entsprechen dem folgenden regulären 

Ausdruck 1 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 verkürzende Schreibweise verwendet. So bezeichnet X3v2R1 

alle Versuche der Reihe 1. X3v2 bezeichnet alle Versuche aller Reihen von Experiment 

3 Variante 2. 

B.2. Übersicht der Experimente 

Die Tabelle B.1 auf Seite 78 listet die durchgeführten Versuchsreihen auf. 

1 Es wird Perl-kompatible Syntax verwendet. Siehe [Vro02]. 

77

B. Versuche 

Versuche 

Reihe 

Variante 

Experiment 

Erläuterung 

1 1 1 unterschiedliche Übertragungsraten im WLAN 1781 57 

1 1 2 unterschiedliche Duty Cycles (Störungen) 1793 59 

1 2 1 Bluetooth gegen WLAN 1799 12 

2 1 1 Verwaltungsaufwand – komplett verworfen 1763 10 

2 1 2 Verwaltungsaufwand 1820 20 

3 1 1 identische Prozessoren 1805 25 

3 1 2 identische Prozessoren – einer startet deutlich früher 1805 10 

3 1 3 identische Prozessoren – der andere startet deutlich früher 1805 10 

3 2 1 unterschiedliche Prozessoren – schwächerer startet deutlich früher 1805 15 

3 2 2 unterschiedliche Prozessoren – stärkerer startet deutlich früher 1805 15 

3 2 3 unterschiedliche Prozessoren – schwächerer startet deutlich früher 1808 15 

5 1 1 zeitliche Entkopplung 1808 16 

5 1 2 zeitliche Entkopplung – Versuch X5K verworfen 1816 21 

Software 

Tabelle B.1.: Übersicht der durchgeführten Experimente mit Softwareversion und Anzahl der ausgeführten Versuche. Versuche, die 

verworfen wurden, wurden bei der Auswertung zu keinem Zeitpunkt berücksichtigt. 

78

B. Versuche 

B.3. Versuchsaufbau 

Die Grafiken auf den Seiten 80 bis 82 stellen den Versuchsaufbau dar. Abbildung B.1 

zeigt die Legende. 

Hostname 

Anwendung 

IP 

IP 

IP 

Bt 

ein Linutop Notebook 

IPn 

Ethernet 

virtuelles 

System 

Subnetz (IP) / 

Verbindungstechnik (Bt, Bluetooth) 

WLAN im Infrastruktur-Modus 

WLAN im Ad-Hoc-Modus 

Bt 

IPn Bt 

Bluetooth 

IP1 

IP2 

Desktop 

direkte Verbindung möglich keine direkte Verbindung 

IP IP 

IP IP 

vereinfacht 

IPx 

IPy 

Bt 

IP2 

IP IP 

IP IP 

Abbildung B.1.: Legende der Versuchsskizzen. 

79

B. Versuche 

debian 

Speicher 

IP1 

linutop 

Dummy 

IP1 

IP2 

debian 

Speicher 

IP1 

linutopk 

Dummy 

IP1 

IP2 

Ethernet 

Ad-Hoc Ad-Hoc 

Enif 

Download 

IP2 

(a) Variante 1 

Ethernet 

Ad-Hoc Bluetooth 

linutop2 

Download 

IP2 Bt 

(b) Variante 2 

Abbildung B.2.: Versuchsaufbau von Experiment 1. 

Kajam 

Konverter 

IP1 

linutop2 

Dummy 

IP1 

IP1 

linutop 

Dummy 

IP2 

Kajam 

Konverter 

IP1 Bt 

80

B. Versuche 

Enif 

Konverter 

IP1 

IP2 

linutopk 

Rekorder 

IP1 

linutop2 

Download 

Ad-Hoc 

IP2 

Eth. 

debian 

Speicher 

IP1 

linutop2 

Download 

IP2 

Inf. 


Inf. 

Ad-Hoc 

debian 

Speicher 

IP1 

Hyadum-II 

Konverter 

IP2 IP3 

Inf. 

Ethernet 


linutopk 

Rekorder 

IP1 

Enif 

Dummy 

IP1 

linutop 

Download 

IP3 

IP3 

81

B. Versuche 

linutop 

Konverter 

IP 

linutop 

Konverter 

IP 

Ethernet 

debian 

Speicher 

IP 

Ethernet 

Ethernet Ethernet 

Ethernet 

Ethernet 

Enif 

Download 

IP 

(a) Variante 1 

debian 

Speicher 

IP 

linutop2 

Download 

IP 

(b) Variante 2 

Ethernet 


linutop2 

Konverter 

IP 

Enif 

Konverter 

IP 

Ethernet 

82

B. Versuche 

B.4. Hard- und Softwarespezifikationen 

Die Tabellen B.2, B.3 und B.4 geben Auskunft über die in den Versuchen genutzte Hardund 

Software. Das System debian wurde virtualisiert. Das Wirtssystem war Kajam. 

Hostname Betriebssystem Java Laufzeitumgebung 

debian Debian Linux 5.0 OpenJDK Runtime Environment 

(build 1.6.0 0-b11) 

Enif Mac OS X 10.4.11 Java(TM) 2 Runtime Environment, 

Standard Edition 

Hyadum-II openSUSE 11.1 

(build 1.5.0 19-b02-306) 

OpenJDK Runtime Environment 

(IcedTea6 1.6.2) (suse- 

0.1.1-i386) 

Kajam Windows Vista Home Java(TM) SE Runtime Envi- 

Premium 64 Bit, SP 2 ronment (build 1.6.0 17-b04) 

linutopX Ubuntu 9.04 Server OpenJDK Runtime Environment 

(IcedTea6 1.4.1) (6b14- 

1.4.1-0ubuntu12) 

Tabelle B.2.: Übersicht der Versuchsrechner und ihrer Softwareausstattung. 

Prozessorkerne 

Hostname Prozessor 

debian Intel Core 2 Duo CPU E8400 1 3.000 1536 

Enif PowerPC G4 1 1.200 768 

Hyadum-II AMD Athlon XP 2000+ 1 1.666 1024 

Kajam Intel Core 2 Duo CPU E8400 2 3.000 8192 

linutopX AMD Geode LX700 1 433 256 

Tabelle B.3.: Übersicht der Versuchsrechner und die Eckdaten ihrer Hardwareausstattung. 

Taktfrequenz [MHz] 

Arbeitsspeicher [MB] 

83

B. Versuche 

Handels- Produkt Bezeichnung unter Linux 

marke 

(lsusb) 

Hama WLAN USB- Ralink Technology, Corp. 

Stick (802.11g) RT2501USB Wireless Adapter 

TP-Link TL-WN321G Ralink Technology, Corp. 

RT2501USB Wireless Adapter 

Anycom USB-200 Broadcom Corp. Bluetooth 

MSI Star Key 3.0 

2.0+EDR dongle 

Integrated System Solution Corp. 

KY-BT100 Bluetooth Adapter 

MSI BToes EDR Mi- Cambridge Silicon Radio, Ltd Bluecro 

Dongle tooth Dongle (HCI mode) 

Vivanco Bluetooth V2.0 

Dongle 

Cambridge Silicon Radio, Ltd Bluetooth 

Dongle (HCI mode) 

Tabelle B.4.: Übersicht der externen Netzwerkperipherie. 

B.5. Ausgewählte Diagramme 

Einige ausgewählte Diagramme, die die Auswertung der Versuche veranschaulichen, befinden 

sich auf den Seiten 85 bis 87. 

84

B. Versuche 

Kosten 

7000 

6500 

6000 

5500 

5000 

4500 

4000 

3500 

3000 

2500 

Ankündigungen via linutop Ankündigungen via linutop2 

A B C D E F G H I J K L 

Versuch 

Abbildung B.6.: Durchschnittliche Kosten eingehender Ankündigungen des Downloads 

am Download-Rechner in den Versuchen X1v1R1@1M. Die Verbindung 

über linutop2 ist auf 1 MBit/s gedrosselt. 

Kosten 

3500 

3400 

3300 

3200 

3100 

3000 

2900 

2800 

2700 

2600 

2500 


A B C D E F G H I J K L M 

Versuch 




85

B. Versuche 

Kosten 

3500 

3400 

3300 

3200 

3100 

3000 

2900 

2800 

2700 

2600 

2500 



Versuch 




Kosten 

3500 

3400 

3300 

3200 

3100 

3000 

2900 

2800 

2700 

2600 

2500 


A B C D E F G H I J K L M N O P Q R S T 

Versuch 


am Download-Rechner in den Versuchen X1v1R1@auto. Die Verbindung 

über linutop2 verwendet automatische Bitratenwahl. 

86

B. Versuche 

Kosten 

4000 

3800 

3600 

3400 

3200 

3000 

2800 

2600 



Versuch 


am Download-Rechner in den Versuchen X1v1R2@dc80a. Die Verbindung 

über linutop ist nur 80 % der Zeit aktiv. 

Kosten 

4000 

3800 

3600 

3400 

3200 

3000 

2800 

2600 


A B C D E F G H I J K 

Versuch 


am Download-Rechner in den Versuchen X1v1R2@dc100. Beide Verbindungen 

sind zu 100 % aktiv. 

87

Literaturverzeichnis 


[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 ODBA- 

SE 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 ; Mühlhä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 

für Handys, PDA und Co. Mü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, Célio Vinicius N. ; Saade, Dé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 ; Gä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 

[Lüd07] Lüders, Christian: Lokale Funknetze : Wireless LANs (IEE 802.11), Bluetooth, 

DECT. 1. Auflage. Würzburg : Vogel Buchverlag, 2007 

[MC02] Meier, René ; 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] Mü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, Jörg: Wireless LANs : 802.11-WLAN-Technologie und praktische 

Umsetzung im Detail. 2. Auflage. Hannover : Heise Zeitschriften Verlag, 

2006 

[Rec08] Rech, Jörg: Ethernet : Technologien und Protokolle fü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 AU- 

UG97, 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. Mü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: Mä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

Selbstständigkeitserklärung 

Ich erkläre, dass ich die vorliegende Arbeit selbstständig und nur unter Vorlage der 

angegebenen Literatur und Hilfsmittel angefertigt habe. 

Rostock, den 25. Februar 2010 

Roland Seuchter

B C D A E F O - Lehrstuhls für Informations- und ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?