Veröffentlichen auch Sie Ihre Arbeiten - es ist ganz einfach!
Mehr InfosDiplomarbeit, 2003, 180 Seiten
Ingenieurwissenschaften - Nachrichtentechnik / Kommunikationstechnik
Diplomarbeit
1,3
1. Einleitung und Motivation
1.1 Zielsetzung der Arbeit und Stellung im Gesamtprojekt
1.2 Gliederung der Arbeit
2. Grundlagen
2.1 Drahtlose, mobile Ad-Hoc-Netzwerke
2.2 Gruppenkommunikation
3. Das SDL2C-Framework
3.1 Struktur
3.2 Prozessadressierung
3.3 Prozessinteraktion
3.4 Timer
3.5 Anwendungsbeispiel für das SDL2C-Framework
4. Entwurf eines Adressierungsschemas
4.1 Vermeidung aufwendiger Adressumsetzungen
4.2 Verwendung eines hierarchischen Adressraumes
4.3 Geeignete Unterstützung von Gruppenkommunikation
4.4 Anwendungsbeispiel für das „Hierarchische Gruppenschema“
4.5 Reduktion des Adressierungsoverhead
5. Entwurf eines Rahmen-Formats
5.1 Grundaufbau des Rahmens
5.2 Aufbau des Optionsfeldes
6. Gruppenmanagement
6.1 „Single-Hop“-Gruppenmanagement
6.2 „Multi-Hop“-Gruppenmanagement
7. Entwicklung der MAC-Schicht
7.1 Spezifikation der MAC-Schicht
7.2 Implementation der MAC-Schicht
7.3 Die Schnittstelle der MAC-Schicht
7.4 Simulation und Test
8. Zusammenfassung und Ausblick
Literaturverzeichnis
Anhang
A. SDL2C-Framework
B. SDL2C-Implementation „Ping-Pong“
C. SDL-Prozeduren der MAC-Schicht-Spezifikation
D. SDL2C-Implementation der MAC-Schicht (Block und Prozesse)
E. SDL2C-Implementation der MAC-Schicht (Prozeduren)
F. SDL-Spezifikation „Alice und Bob“
G. SDL2C-Implementation „Alice und Bob“
H. SDL-Spezifikation „Multihop“
Mobile Kommunikation wird heute in vielen Bereichen des modernen Lebens benötigt. Einer der wichtigsten Bereiche, in der diese Kommunikationsform Verwendung findet, ist neben militärischen Anwendungen der Zivil- bzw. Katastrophenschutz. Im Gegensatz zur Mobiltelefonie im privaten Sektor sind die Anforderungen an Stabilität und Sicherheit des Netzes in diesen Bereichen existentiell, da davon unmittelbar Menschenleben betroffen sein können.
In den letzten Jahren kamen immer neue Anforderungen an mobile Kommunikationssysteme auf. Reine Sprachdienste, zu Beginn noch analog, sollten nach und nach durch volldigitale Datendienste abgelöst werden, damit neben Sprache auch grafische Kartendaten oder Datenbankabfragen übertragen werden können.
Auch die Möglichkeit zur effizienten und komfortablen Gruppenkommunikation gewinnt zunehmend an Bedeutung, denn gerade im Katastrophenschutz müssen Daten meistens zwischen Personengruppen ausgetauscht werden, anstatt nur zwischen Einzelpersonen.
All diese Funktionalität setzt eine möglichst schnelle, sichere und stabile Übertragung der Daten voraus, im Hinblick auf Katastrophengebiete vor allem auch in Regionen ohne bestehende Kommunikationsinfrastruktur und über größere Entfernung hinweg, als es mit den meisten Single-Hop-Netzen möglich ist. Deshalb sind herkömmliche Technologien, wie mobile Dienste auf GSM-Basis oder Funkgeräte, ungeeignet. Eine mögliche Alternative sind daher die drahtlosen, mobilen Ad-Hoc-Netzwerke, da diese sowohl Ausfallsicherheit als auch relativ große Reichweite ohne teure Infrastruktur erlauben (Details siehe Abschnitt 2.1).
Diese Arbeit ist Teil eines größeren Projektes der AG Rechnernetze an der Universität Kaiserslautern, in dem ein neuer, leistungsfähiger Treiber und dazu passende Protokolle für drahtlose, mobile Ad-Hoc-Netzwerke auf Grundlage der „Wireless LAN“-Technologie [1] entwickelt werden sollen. Diese Technologie erlaubt zwar schon lange die Verwendung eines Ad-Hoc-Modus, jedoch existieren derzeit noch keine Spezifikationen oder Implementierungen für dessen Einsatz in einer Multi-Hop-Umgebung. Bei der Entwicklung wurde absichtlich auf Kompatibilität zu vorhandenen Netzwerk-Protokollen verzichtet, um vollkommene Flexibilität für eine Maßschneiderung der Verfahren zu gewährleisten, welche in diesem Treiber und in darüber liegenden Schichten Verwendung finden. Die Domäne des Katastrophenschutzes hat sich aufgrund ihrer vielfältigen Anforderungen als sehr geeignet für den Test der Praxistauglichkeit dieses Projektes erwiesen, und wird deshalb auch immer wieder aufgegriffen werden.
Das besondere Augenmerk der vorliegenden Arbeit richtet sich auf den Aspekt der Adressierung und Gruppenkommunikation innerhalb der MAC-Schicht [2] des Treibers. Eine weitere, parallel dazu entstandene Arbeit [3], welche ebenfalls Funktionalität der MAC-Schicht beinhaltet, beschäftigt sich mit dem Problem der Dienstgüte („Quality of Service“) in diesen Netzwerken.
Die Entwicklung des Treibers findet unter LINUX statt und basiert auf dem existierenden WLAN-Treiber „linux-wlan-ng“ [4] für den Prism2-WLAN-Chipsatz [5].
Diese Arbeit gliedert sich in neun Kapitel. Kapitel 1 umfasst die Einleitung und Zielsetzung, in Kapitel 2 werden dann die in der Einleitung erwähnten und in späteren Teilen der Arbeit unbedingt benötigten Grundlagen vertieft. Dann folgt Kapitel 3, in dem ein Framework für die Umsetzung von SDL-Spezifikationen in ausführbaren Programmcode vorgestellt wird, welches in der kompletten Treiberentwicklung des Projektes Verwendung findet. Kapitel 4 und 5 beschäftigen sich ausführlich mit dem Entwurf eines Adressierungsschemas und eines Rahmenformates für die MAC-Schicht, Kapitel 6 demonstriert das Gruppenmanagement unter Verwendung eben dieses Adress- und Rahmen-Formats. Die MAC-Schicht selbst wird schließlich in Kapitel 7* vollständig spezifiziert und implementiert. Im 8. Kapitel geht es dann um Simulation und Test dieser MAC-Schicht, und im letzten Kapitel 9 wird ein Ausblick auf die zukünftigen Projektphasen im Zusammenhang mit dieser Arbeit gegeben.
*) Kapitel 7 entstand vollständig in gemeinsamer Zusammenarbeit mit Daniel Schmidt [3] und ist Bestandteil beider Arbeiten.
Der hier entwickelte Treiber ist speziell auf die Bedürfnisse von drahtlosen, mobilen Ad-Hoc-Netzwerken [6] zugeschnitten. Diese werfen aufgrund ihrer besonderen Eigenschaften eine Vielzahl praktischer Probleme auf, gewährleisten dafür aber auch ein Maximum an Flexibilität. Im Folgenden werden nun einige der Vor- und Nachteile dieser Netzwerkstruktur aufgezeigt und im Detail behandelt, um einen besseren Einblick in die Schwierigkeiten der Treiberentwicklung zu geben.
In drahtlosen Netzwerken liegt, im Gegensatz zu verkabelten Netzen, wie zum Beispiel dem Ethernet, keine feste physikalische Infrastruktur vor. Eine zusätzliche Eigenschaft von Ad-Hoc-Netzwerken ist das Fehlen jeglicher, also auch funktionaler Infrastruktur, wie sie bei WLAN durch den „infrastructure“-Modus möglich ist, zum Beispiel für „last-hop“-WLAN-Netzwerke. Die Knoten in einem Ad-Hoc-Netzwerk sind somit alle gleichberechtigte Teilnehmer.
Die Mobilität bietet den Teilnehmern zudem die Möglichkeit, jederzeit ihren Standort relativ zu den anderen mit variabler Geschwindigkeit zu verändern. Ein weiterer wichtiger Vorteil dieser Netze ist ihre Multi-Hop-Fähigkeit. Dadurch dient jeder Netzwerkknoten als potentieller Router, und kann per „store-and-forward“ wesentlich größere Entfernungen überbrücken, als es mit nur einem Hop möglich wäre.
Mobilität in Multi-Hop-Netzen führt natürlich zu einigen Schwierigkeiten bei der Wegfindung, welche jedoch nicht innerhalb der MAC-Schicht geschieht und in dieser Arbeit deshalb nur am Rande behandelt wird (siehe Kapitel 9). Vor allem wenn sich die Knoten zu schnell bewegen, ist eine stabile Kommunikation über größere Entfernungen nahezu unmöglich [7].
Ein grundlegendes Problem ist schon die Erkennung von Kollisionen in Funknetzen. Während im Ethernet eine Kollision bereits während der Übertragung von allen Teilnehmern im näheren Umkreis festgestellt wird, ist dies in drahtlosen Netzen nicht möglich. Bei der Verwendung von nur einer Antenne ist eine Kollision während des Sendens schon aus technischen Gründen nicht erkennbar, da die Sendeleistung die Empfangsleistung weit übersteigt, aber auch bei getrennten Sende- und Empfangseinheiten ist diese nicht an jeder Stelle des Netzes zu beobachten, sondern nur am Punkt des Auftretens. Deshalb funktionieren Techniken wie CSMA/CD („Carrier Sense Multiple Access with Collision Detection“) in drahtlosen Netzen nicht, alle korrekt empfangenen Daten müssen also vom Empfänger bestätigt werden, um einen sicheren Transfer zu gewährleisten. Dies musste insbesondere bei der Entwicklung der MAC-Schicht (siehe Kapitel 7) berücksichtigt werden.
Kollisionen sind in drahtlosen Netzwerken aufgrund des verwendeten Mediums auch schwieriger zu vermeiden als in herkömmlichen Kabelnetzen, wo der Einsatz von „Carrier-Sense“-Verfahren verhindert, dass eine laufende Übertragung gestört wird. Das Medium wird einerseits von allen Knoten im Einzugsbereich der jeweiligen Sender gleichzeitig benutzt, andererseits lässt sich die Belegung des Mediums nicht von allen Knoten aus feststellen, da sich die Sender aufgrund der limitierten Reichweite nicht unbedingt gegenseitig „sehen“ können. Dieses Problem ist in Abbildung 2.1 noch einmal dargestellt. Sender 2 sendet Daten an den Empfänger, Sender 1 sieht diese Belegung des Mediums jedoch nicht und beginnt deshalb seinerseits mit einer Übertragung. Dadurch kommt es schließlich zur Kollision der Daten beim Empfänger.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.1: Das „Hidden-Terminal“-Problem
Dieses Problem ist unter dem Namen „Hidden-Terminal“ bekannt. Eine mögliche und weit verbreitete Lösungsmöglichkeit ist der RTS/CTS-Handshake, welcher im folgenden Kapitel genauer beschrieben wird.
Abbildung 2.2 zeigt den RTS/CTS-Handshake, mit dem viele der auftretenden Kollisionen bei der Datenübertragung verhindert werden können. Dabei wird zuerst die Sendebereitschaft mit einer speziellen RTS-Nachricht („Request To Send“) dem Empfänger bekannt gegeben, welche auch eine Reservierungsdauer beinhaltet, für die das Medium belegt sein wird. Dieser antwortet mit einem CTS („Clear To Send“) an alle Stationen in seiner Reichweite und übermittelt dabei ebenfalls die Reservierungsdauer. Der Sender kann dann mit der Übertragung seiner Daten beginnen, ohne dass andere Sender in Reichweite des Empfängers dies innerhalb der angegebenen Zeit ebenfalls versuchen. Der korrekte Empfang der Daten wird schließlich vom Empfänger bestätigt.
Dieser Mechanismus hat jedoch auch einige Nachteile. Zum Einen müssen die RTS- und CTS-Nachrichten sehr kurz sein im Vergleich zu den zu übertragenen Daten, da ansonsten die Kollisionswahrscheinlichkeit dieser Nachrichten nicht geringer ist als bei einem herkömmlichen Datentransfer. Zum Anderen wird durch den Handshake ein bedeutender Teil der Bandbreite des Mediums verbraucht, und auch die Verzögerung der Daten steigt zwangsläufig an.
Es bleibt noch anzumerken, dass der erfolgreiche Ablauf des Handshakes keine Garantie für einen kollisionsfreien Datentransfer bietet, da durch die Kollision von Nachrichten eine solche Reservierung auch jederzeit fehlschlagen kann.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.2: Datentransfer mit RTS/CTS-Handshake
Durch die Verwendung eines gemeinsamen Mediums zusammen mit „Carrier-Sense“-Verfahren in der MAC-Schicht wird in drahtlosen Netzen ein großer Teil der verfügbaren Bandbreite verschwendet, da oft nur wenige der tatsächlich anstehenden Kommunikationen zur gleichen Zeit erfolgen können. Dieses Problem ist als „Exposed-Node“-Problem bekannt und in Abbildung 2.3 dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.3: Das „Exposed-Node“-Problem
Dabei überträgt Sender 1 Daten an Empfänger 1. Sender 2 will jedoch zur gleichen Zeit auch eine Übertragung beginnen, und zwar an Empfänger 2. Da Sender 2 jedoch innerhalb der Sendereichweite von Sender 1 liegt, erkennt dieser das Medium als belegt und beginnt somit seinerseits nicht mit der Übertragung.
Eine Möglichkeit zur Lösung dieses Problems wäre der totale Verzicht auf „Carrier-Sensing“, was jedoch andererseits sofort wieder zu neuen Kollisionsquellen führt. Ein anderer Ansatz ist in [8] aufgeführt und verwendet eine Scheduling-Technik zur besseren Ausnutzung des Mediums.
Bei der Gruppenkommunikation handelt es sich um eine Verallgemeinerung des Sender/Empfänger-Konzepts beim Datenaustausch, dem Unicast. Hierbei können ganze Gruppen von Teilnehmern untereinander kommunizieren. Natürlich ließe sich dies auch auf einzelne Unicast-Verbindungen abbilden, jedoch nur mit einem großen Performanceverlust zu Lasten von Bandbreite und Delay. Viel besser ist es, einen Multicast-Mechanismus [9] zu verwenden, bei dem die Daten möglichst oft auf gemeinsamen Wegen zu den Zielknoten gelangen, und somit viel seltener kopiert werden müssen (Abb. 2.4). In dieser Arbeit beschränkt sich der Multicast auf die Kommunikation von einem Sender mit einer Gruppe von Empfängern. Bei einer Gruppe von Sendern kommen weitere Probleme hinzu, insbesondere im Bereich der Synchronisation der Nachrichten, die dann in höheren Schichten erfolgen muss. Anwendungsgebiete für Multicast sind unter anderem Videostreaming und Chatsysteme.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.4: Unicast versus Multicast
Die Umsetzung eines solchen Mechanismus setzt sowohl eine geeignete Adressierung der Knoten (siehe Kapitel 4) als auch eine Möglichkeit zum Gruppenmanagement (siehe Kapitel 6) voraus. Im Gegensatz zu den bereits vorhandenen und im Internet weit verbreiteten Implementierungen wurde die Fähigkeit zum Multicast hier bereits in der MAC-Schicht verankert, was eine spätere Nutzung in höheren Schichten wesentlich erleichtert.
Für die Spezifikation der MAC-Schicht wurde SDL96 [10] („Specification and Description Language“) verwendet. SDL eignet sich hervorragend zur Beschreibung von Protokoll-Designs und wird schon seit Jahren erfolgreich im Kommunikationsbereich eingesetzt. Die Umsetzung der Spezifikation innerhalb des Kernel-Space erfolgt durch die manuelle Implementierung der SDL-Prozesse als Linux-Modul [11] unter C [12].
Um die Transformation zu erleichtern, wurde ein Framework geschrieben, basierend auf dem Code von Dominik Gummel [13], welches Funktionen für eine Auswahl von SDL-Sprachelementen bereitstellt. Einige Features, darunter „Spontane Transitionen“ und „Enabling Conditions“, werden nicht unterstützt. Dieses SDL-Subset hat sich für die hier betrachteten Protokollentwürfe als ausreichend erwiesen, gleichzeitig wird dadurch die Komplexität der im Kernel laufenden Module limitiert. Im Folgenden werden nun die unterstützten Konstrukte mit ihren Implementierungskonzepten ausgewiesen, Details finden sich in Anhang A.
Aus Effizienzgründen werden, außer den von Systemen und Blöcken aggregierten Prozessen, keine weiteren Strukturierungsmöglichkeiten von SDL, wie zum Beispiel Procedures oder Services, explizit unterstützt. Diese lassen sich aber durch #INCLUDE-Direktiven oder C-Funktionen nachbilden. Im Normalfall ist eine Strukturexpansion der Spezifikation auf die Ebene der reinen Prozesse jedoch die zu bevorzugende Möglichkeit, vor allem wenn es sich bei den Protokollentwürfen um einfache Strukturen mit nur wenig Hierarchieebenen handelt.
Aufgrund der flachen Struktur des SDL2C-Frameworks sind dort auch keine speziellen Transformationen für Kanäle und Signalwege nötig, die Blöcke und Prozesse miteinander verbinden. Der Austausch von Signalen findet stattdessen über globale Variablen statt, welche die einzelnen SDL-Prozesse repräsentieren.
Die Adressierung der Prozesse geschieht in SDL vorwiegend implizit. Explizite Adressierung ist nur dann notwendig, wenn mehrere Signalwege möglich sind oder mehrere Instanzen eines Prozesses existieren.
Das Framework bietet zwei verschiedene Kommunikationsmöglichkeiten für die Umsetzung der Prozesse, welche durch verschiedene Sendefunktionen explizit ausgewählt werden. Falls die kommunizierenden Prozesse lokal ablaufen, also in einem Modul, erfolgt die Adressierung einfach explizit über deren Instanzvariable.
Bei einer modulübergreifenden Kommunikation über Rechnergrenzen hinweg, wie sie bei Netzwerkprotokollen zwangsläufig auftritt, wird der Zielprozess dagegen implizit adressiert. Nur einer der lokalen Prozesse darf diese Kommunikationsform wählen, damit keine Konkurrenzsituationen beim Zugriff auf das Netzwerkinterface auftreten. Dieser Prozess registriert sich beim Start an ein bestimmtes unbenutztes Interface, über welches dann alle Signale verschickt und empfangen werden. Diese Signale enthalten keine Zieladresse, sondern werden allen empfangenden Prozessen zugestellt, die sich ebenfalls am Netzwerk registriert haben.
Die Prozessinteraktion in SDL folgt einem asynchronen, nichtblockierenden, gepufferten Sender/Empfänger-Schema mittels Signalen. Die Nachbildung dieses Schemas in SDL2C erfolgt über das Schreiben der Signale des Senders in eine Queue, die dem jeweiligen Empfänger zugeordnet ist. Gleichzeitig wird der Queue-Handler des Empfängers angestoßen, welcher dann unabhängig vom Sender alle Signale der Reihe nach aus der Queue entnimmt und die damit verbundenen Aktionen abhängig vom aktuellen Zustand ausführt, bis die Queue keine Signale mehr enthält. Eine Ausnahme bilden die Prioritätseingaben, bei denen Signale aus der Queue vorgezogen werden müssen, dazu mehr in Abschnitt 3.3.2.
Sowohl diese Prioritätseingaben, als auch die Aktionen, müssen vom Entwickler bereits während des Entwurfs festgelegt werden. Die Aktionen werden dann vom Framework automatisch in ein Array übertragen, welches zu jedem Zustand/Signal-Paar einen Verweis auf die zugehörige Aktion enthält, die Prioritätseingaben kommen in eine spezielle Liste (PL) des Queue-Handlers. Die Aktionen entsprechen entweder Zustandstransitionen, welche im Abschnitt 3.3.1 genauer beschrieben werden, oder dem SAVE-Konstrukt zum expliziten Retten von Signalen, siehe dazu Abschnitt 3.3.3. Falls keine solche Aktion im aktuellen Zustand verfügbar ist, wird das Signal ohne Auswirkung gelöscht, was der impliziten Konsumierung von Signalen in SDL entspricht (Discard).
Der gesamte Ablauf ist in Abbildung 3.1 noch einmal übersichtlich graphisch dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.1: Ablauf der Prozessinteraktion in SDL2C
Meistens soll durch ein Signal ein Zustandsübergang im Empfängerprozess ausgelöst werden. Für jede Transition muss eine Funktion vorhanden sein, welche diese repräsentiert, und am Ende den Zustand bei Bedarf explizit wechselt. Dieser neue Zustand kann dabei natürlich auch von vorher deklarierten Prozess-Variablen oder Parametern eines Signals, siehe dazu auch Abschnitt 3.3.4, abhängig sein.
Diese Transitionsfunktionen haben zwar einen festgelegten Funktionskopf, müssen ansonsten aber vollständig vom Entwickler implementiert und den entsprechenden Transitionen zugeordnet werden. Innerhalb der Funktionen ist prinzipiell beliebiger C-Code möglich, was auch die Realisierung von SDL-Konstrukten wie DECISION oder ANY erlaubt. Auch die SDL-Timer, welche in Abschnitt 3.4 behandelt werden, können in diesen Funktionen aktiviert oder gelöscht werden.
In SDL gibt es die Möglichkeit, bestimmte Eingaben anderen vorzuziehen, so genannte Prioritätseingaben. Diese müssen vom Entwickler als solche während des Entwurfs markiert werden und werden dann bei der Entnahme der Signale aus der Queue bevorzugt behandelt. Das FIFO-Prinzip der Queues muss also ausnahmsweise umgangen werden.
Die Umsetzung erfolgt durch lineares Durchsuchen der Queue und den Vergleich jedes Signals mit der Liste der Prioritätseingaben durch den Queue-Handler. Falls ein solches gefunden wird, wird es aus der Queue entnommen und konsumiert.
Ein weiteres, wichtiges SDL-Element ist das SAVE-Konstrukt. Mit Hilfe von SAVE’s können in einem bestimmten Zustand, in dem das aktuelle Signal nicht verarbeitet werden soll, aber auch nicht verloren gehen darf, dieses explizit gerettet werden. Diese SAVE’s müssen für jeden Zustand und jedes Signal, auf das sie einwirken sollen, in das Array aufgenommen werden.
Realisiert wird das SAVE-Konstrukt in SDL2C nämlich durch den Aufruf einer Dummy-Funktion, welche alle zu rettenden Signale zuerst in eine temporäre Queue einreiht. Am Ende der nächsten Transition wird dann diese Queue an den Anfang der normalen Signalqueue gehängt. Dadurch geht kein Signal verloren, und die ursprünglichen Reihenfolge der Signale bleibt erhalten.
SDL sieht die Übergabe von Parametern durch Signale vor. Die Umsetzung dieses Mechanismus wird jedoch dadurch verkompliziert, dass die Signale über das Netzwerk im Payload von Datenrahmen verschickt werden sollen, wodurch die Parametergrenzen nicht mehr implizit erkennbar sind. Dazu wird jedes Signal mitsamt seiner Parameter, die von variabler Anzahl, Typisierung und Größe sind, mittels eines Transfersyntax in einen String kodiert.
Als Ansatz für die Kodierung wurden die Kommunikationsroutinen in PVM [14] („Parallel Virtual Machine“) verwendet. PVM wurde ursprünglich für die Kommunikation von virtuellen Parallelrechnern entwickelt und hatte die selbe Problemstellung bei der Übergabe verschiedenartigster Parameter über ein Netzwerk zu bewältigen. Die Grundidee besteht darin, eine temporäre Tabelle anzulegen, die einzelnen Parameter mit ihrem jeweiligen Typ einzeln hinzuzufügen und abschließend die Tabelle mit zusätzlichen Kodierungsinformationen so zu einem String zu konvertieren, dass er sich auf Empfängerseite ohne großen Aufwand wieder in die einzelnen Parameter zerlegen lässt. Ein Beispiel dazu zeigt Abbildung 3.2.
Das SDL2C-Framework unterstützt bisher explizit nur zwei Datentypen, nämlich ganze Zahlen und Byte-Felder. Auf Fließkommazahlen wurde verzichtet, da diese beim Protokollentwurf keine besondere Rolle spielen, alle anderen Typen, wie zum Beispiel nullterminierte Strings, lassen sich jedoch leicht abbilden. Abschließend folgt ein Beispiel für eine solche Konvertierung, bei der die Parameter „Hallo Welt“ und 42 übertragen werden sollen. In der Praxis muss natürlich auch noch der eigentliche Signalbezeichner mitkodiert werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.2: Beispiel für eine Parameterkodierung in SDL2C
SDL kennt auch Timer, die zu einem definierten Zeitpunkt ein Signal an den Prozess verschicken, welcher den Timer gestellt hat.
Diese SDL-Timer lassen sich am effizientesten mit den bereits im Kernel vorhandenen Timer-Routinen implementieren. Mit diesen Routinen lassen sich Betriebssystem-Timer setzen, löschen und so konfigurieren, dass nach einer bestimmten Zeitspanne automatisch eine vorher festzulegende C-Funktion aufgerufen wird.
Eben diese Routinen werden im SDL2C-Framework in Funktionen gekapselt, um einen noch komfortableren Einsatz zu ermöglichen. Der Entwickler muss sich dabei nicht um die Signal-Behandlung der Timer kümmern. Die nach Ablauf eines Timers aufgerufene Funktion stellt dazu einfach das zu dem jeweiligen Timer gehörige Signal in die Empfangsqueue des Prozesses, wo es wie ein explizit gesendetes Signal verarbeitet wird (siehe Abschnitt 3.3).
Um den Einsatz des SDL2C-Frameworks zu demonstrieren, wird jetzt eine einfache Anwendung, ein leicht modifiziertes „Ping-Pong“-Protokoll mit Signalparametern, zuerst in SDL spezifiziert, und danach in C implementiert. Dabei werden alle Schlüsselstellen des Codes aufgeführt und erklärt, welche Teile der SDL-Spezifikation diese realisieren. Die Kommunikation der Prozesse findet in diesem Beispiel ausschließlich implizit über das Netzwerk statt (siehe Abschnitt 3.2).
Die #INCLUDE-Direktiven wurden der Übersichtlichkeit halber ausgelassen, da diese keine direkte SDL-Funktionalität repräsentieren. Der komplette, lauffähige Quelltext findet sich im Anhang B.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.3: SDL-System PINGPONG
Das SDL-System ist in Abbildung 3.3 dargestellt. Der Kanal WLAN zwischen den beiden Blöcken entspricht der Funkstrecke zwischen den beiden kommunizierenden Protokolleinheiten. Hier werden auch die ausgetauschten Signale und die Richtung des Informationsflusses definiert: Das Signal PING kann nur vom Block PING an den Block PONG gesendet werden, für das Signal PONG ist es genau umgekehrt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.4: SDL-Blockbeschreibung PING und PONG
Die SDL-Blockbeschreibung in Abbildung 3.4 zeigt die Anbindung der Prozesse an den Kanal WLAN mittels der Signalwege PINGWLAN und PONGWLAN. Auch hier sind die verwendeten Signale PING und PONG angegeben.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.5: SDL-Diagramm des PING-Prozesses
Abbildung 3.5 zeigt das SDL-Diagramm des PING -Prozesses. In der Initialisierungsphase des Prozesses wird ein Timer TIMEOUT auf drei Sekunden gesetzt, ein Signal PING mit dem zu 1 initialisierten Parameter N über das Netzwerk geschickt, und in den Zustand RECEIVESOME gewechselt. Der Timer sorgt dafür, dass bei einem auf dem Transfer verloren gegangenen PING dieses Signal nach drei Sekunden wiederholt wird.
In diesem Zustand wird auf das Eintreffen der Signale TIMEOUT und PONG reagiert, jedes andere Signal würde implizit konsumiert.
Beim Eintreffen eines TIMEOUT wird der Timer wieder auf den ursprünglichen Wert zurückgesetzt und das PING -Signal mit dem gleichen Parameter noch einmal verschickt. Dann wechselt der Automat in den vorherigen Zustand.
Wenn er stattdessen ein PONG aus dem Netz empfängt, wird der von diesem übertragene Parameter inkrementiert und ausgegeben. Falls dieser Wert größer als 1000 ist, wird der Timer gestoppt und der Prozess geht in seinen Endzustand STOP, ansonsten wird der neu berechnete Wert für N wieder mit einem PING verschickt, der TIMEOUT -Timer neu gesetzt und in nach RECEIVESOME zurückgewechselt.
Dieser Automat berechnet mit Hilfe des PONG -Automaten (siehe Abschnitt 3.5.2) die Funktion Abbildung in dieser Leseprobe nicht enthalten, wobei der Funktionswert des vorangegangenen Durchlaufs als Eingabe für den nächsten dient. Die Ausgabe ist demnach 2, 5, 26, 677 und 458330. Nach fünf Durchgängen wird also die Abbruchbedingung von 1000 überschritten und der Automat erreicht seinen Endzustand, es werden dann kein weiteren Signale mehr verschickt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.6: SDL-Diagramm des PONG-Prozesses
In Abbildung 3.6 ist der PONG -Prozess in SDL dargestellt. Dieser ist im Vergleich zum PING -Prozess sehr einfach aufgebaut, da er nur eine Transition besitzt.
Zu Beginn befindet sich dieser im Zustand SQUARE. Bei einem eintreffenden PING -Signal wird dessen Parameter übernommen, mit sich selbst multipliziert (quadriert) und als Parameter mit einem PONG -Signal an den PING -Prozess zurückgeschickt. Daraufhin wechselt er wieder in den vorherigen Zustand zurück.
Dieser Automat berechnet somit also die Hilfsfunktion Abbildung in dieser Leseprobe nicht enthaltenfür den PING -Automaten.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.7: Deklarationen des PING-Prozesses
Zuerst wird das „Gerüst“ des SDL2C-Moduls für PING vorgestellt Dazu gehören sowohl die Umsetzung von den im SDL-Diagrammausschnitt in Abbildung 3.7 gezeigten Deklarationen, als auch die Initialisierungsroutinen des Moduls. Außerdem werden auch noch alle benötigten Signale definiert, was in SDL implizit an den Kanälen und Signalwegen außerhalb der Prozess-Diagramme geschieht.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.1: Prozessdeklaration von PING
Die Deklaration des PING -Prozesses lässt sich, wie in Quelltext 3.1 dargestellt, sehr einfach umsetzen. Dazu wird ein neuer struct-Typ Ping eingeführt, welcher eine Verhaltensbeschreibung fsm und einen Timer timeout beinhaltet. Mit diesem Typ wird eine globale Variable ping definiert. Die Variable N wird global als integer definiert und auf 1 gesetzt.
Die Signale werden im Quelltext 3.2 per enum umgesetzt. Dabei müssen sowohl alle aus- und eingehenden, als auch von Timern lokal verschickten Signale aufgenommen werden. Für die zu empfangenden Signale werden zusätzlich noch Textbeschreibungen PingEventNames[] eingeführt, um ein Debugging zu erleichtern.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.2: Signaldefinition des PING-Prozesses
Die Initialisierungs- und Aufräumteile des PING -Moduls, init_module und clean-up_module, sind in Quelltext 3.3 abgebildet. Diese werden automatisch beim Einfügen des Moduls in den Kernel bzw. bei dessen Entladung aufgerufen. Im Initialisierungsteil wird Speicher für den Prozess zugewiesen, und durch den Aufruf der später noch im Detail behandelten Funktion new_ping_machine der endliche Automat des Prozesses gestartet. Im Aufräumteil wird schließlich reservierter Speicher wieder freigegeben und der Prozess ordnungsgemäß beendet.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.3: Initialisierungs- und Aufräumteil des PING-Moduls
Nun folgt die Initialisierung des Automaten, die Umsetzung der Starttransition mit den vom Startzustand ausgehenden Aktionen bis zum Wechsel in den ersten „echten“ Zustand des Automaten, sowie die Definition der Automatenzustände und die Konfiguration der Zustandsübergangsmatrix (siehe Abschnitt 3.3). Abbildung 3.8 zeigt den jetzt betrachteten Ausschnitt des Prozesses.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.8: Startzustand und Zustandsübergänge
Die Zustände werden, ebenso wie die Signale, mit einem Aufzählungstyp realisiert (Quelltext 3.4). Auch gibt es eine Variable PingStateNames, welche Beschreibungstexte der Zustände beinhaltet.
Die Zustandsübergangsmatrix wird durch PingTransitions konfiguriert, in welchem Tripel der Form {Zustand, Signal, Transitionsfunktion} stehen. Der Zielzustand steht dabei erst in der jeweiligen Transitionsfunktion, da dieser von vielen Faktoren abhängen kann. Diese Funktionen folgen später noch im Detail.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.4: Zustandsdefinition und Übergangsmatrix-Konfiguration des PING-Automaten
Die Initialisierung ist durch die Funktion new_ping_machine realisiert, welche in Quelltext 3.5 dargestellt ist. Zuerst wird Speicher für den Automaten des Prozesses reserviert, und der Automat mit FsmNew erzeugt. Die übergebenen Zahlenwerte entsprechen dabei der Anzahl der Transitionen (2), empfangbaren Signale (2), Zustände des Automaten (2) und Prioritätseingaben (0), außerdem werden die Debug-Informationen eingeschaltet (1).
Dann erfolgt die Anmeldung am Netzwerkinterface per FsmRegister. Durch den Parameter -1 wird einfach das nächste verfügbare WLAN-Interface verwendet. Die Umsetzung des SDL-Diagramms vom Startzustand zum Zustand RECEIVESOME folgt in der Funktion INITtrans (Quelltext 3.6), dort wird das erste PING -Signal mit FsmEventSend verschickt, der Timer initialisiert und mit dem Wert 3000 Millisekunden gestartet, und abschließend der Zustand mit Fsm-ChangeState gewechselt.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.5: Initialisierung des PING-Automaten
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.6: Starttransition des PING-Automaten
Als letztes werden noch die Transitionsfunktionen implementiert. Aus der Transitionskonfiguration ergibt sich, dass genau zwei Funktionen TIMEOUTreceive und PONGreceive benötigt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.9: SDL-Transition für TIMEOUTreceive
In Abbildung 3.9 ist TIMEOUTreceive als Automatenausschnitt in SDL dargestellt, Quelltext 3.7 setzt diesen in SDL2C um.
Dazu wird das PING -Signal mit dem zuletzt berechneten Wert für N noch einmal verschickt, und der Timer wieder auf 3000 Millisekunden zurückgestellt. Obwohl der Automat im gleichen Zustand verbleibt, muss trotzdem explizit ein „Zustandswechsel“ per FsmChangeState erfolgen, um die Signalqueues konsistent zu halten.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.7: Transitionsfunktion TIMEOUTreceive
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.10: SDL-Transition für PONGreceive
Abbildung 3.10 zeigt den Automatenteil, der durch PONGreceive umgesetzt werden soll (Quelltext 3.8).
Ein großer Teil dieser Funktion besteht in der Verwendung der in Abschnitt 3.3.4 eingeführten Parameterübergabe. In einer temporären Variable INCOM wird der mit dem PONG -Signal übermittelte int -Parameter durch den Aufruf von getTableEntry zwischengespeichert. Danach wird dieser Wert wie spezifiziert inkrementiert und ausgegeben.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.8: Transitionsfunktion PONGreceive
Für die Funktion getTableEntry wird dabei zum ersten Mal der an die Transitionsfunktionen übergebene Parameter arg ausgewertet. Dieser enthält für alle Transitionen, die durch ein mit Parametern versehenes Signal getriggert werden, einen Zeiger auf eine Tabelle mit den Typen und Werten dieser Parameter.
Nach der Zuweisung des entnommenen Tabellenwertes an N kann sowohl die Variable INCOM als auch die gesamte Tabelle aus dem Speicher entfernt werden. Dabei ist zu beachten, dass deleteTable nicht die Einträge der Tabelle löscht, dies muss für jeden Eintrag explizit geschehen. In diesem Beispiel zeigt INCOM auf den ersten Tabellenwert, womit dieser durch dessen Freigabe automatisch gelöscht wird.
Falls der Wert von N größer als 1000 ist, wird der Timer TIMEOUT angehalten und in den Zustand STOP gewechselt.
Ist der Wert dagegen kleiner, wird der Timer neu gestartet und der neu berechnete Wert von N mit einem PING -Signal verschickt. Abschließend wird der Automat wieder in den Zustand RECEIVESOME versetzt.
Die Implementation des PONG -Prozesses ist der des PING -Prozesses im Grunde sehr ähnlich, zudem ist dieser wesentlich einfacher aufgebaut und besitzt keine Timer. Deshalb werden hier die Quelltextfragmente größer und nicht mehr im Detail beschrieben.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.9: Prozessdeklaration und Signaldefiniton von PONG
Quelltext 3.9 zeigt die Prozessdeklaration und die Definition der Signale für den PONG -Prozess. Auch hier wird eine Hilfsvariable für die Berechnung des jeweiligen Signalparameters benötigt, in diesem Fall der integer X.
Auffällig ist das Auftreten von TIMEOUT als „ausgehendes Signal“, obwohl PONG keine Timer beinhaltet, dies ist jedoch für die konsistente Nummerierung der Signale von Sender- und Empfängerprozess unverzichtbar.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.10: Initialisierung, Transitionen und Zustände des PONG-Moduls
Die Start- und Aufräumroutinen, Zustandsdefinitionen und die Transitions-konfiguration sind in Quelltext 3.10 zusammengefasst. Es gibt nur einen Zustand SQUARE und nur eine Transition, wie man auch leicht an der Spezifikation in Abbildung 3.6 erkennt.
Diese Transition wird in der Funktion PINGreceive realisiert (Quelltext 3.11). Dort wird die Parameterübergabe identisch wie in PONGreceive benutzt, der einzige Unterschied besteht darin, dass der übergebene Wert diesmal nicht inkrementiert, sondern statt dessen quadriert wird.
Abbildung in dieser Leseprobe nicht enthalten
Quelltext 3.11: Transitionsfunktion PINGreceive
Nachdem nun das „Ping-Pong“-Protokoll fertig implementiert ist, kann ein Testlauf der beiden Module und ein Vergleich mit der ursprünglichen SDL-Spezifikation erfolgen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3.11: Testlauf der Implementierung und MSC der Spezifikation
In Abbildung 3.11 sind Ausschnitte der Modul-Logs zu sehen, welche aus der LINUX-Kernel-Logdatei /var/log/messages stammen und für die Präsentation leicht gekürzt und vereinfacht wurden, und ein MSC der Spezifikation, welches mit dem Simulator der Tau-SDL-Suite [15] erstellt wurde.
Jedes verschickte Signal ist im MSC durch einen Pfeil von einem zum anderen Prozess dargestellt, in den Debug-Ausgaben der Module wird diese Kommunikation durch „sending frame“ und „received a frame“ ausgedrückt. Auch die kodierten Rahmen, in denen sowohl die Events als auch alle Parameter stehen, sind hinter „data to send“ und „data received“ abgebildet.
An den übertragenen Rahmen lässt sich erkennen, dass die Byte-Anordnung der Integer-Parameter nicht intuitiv erscheint, sich aber durch die „little endian“-Darstellung der Intel-Prozessoren ergibt. Zum Beispiel steht beim letzten empfangenen PONG ein hexadezimaler Wert von 59FE06 im Rahmen, der übergebene Parameter 458329 entspricht aber eigentlich der hexadezimalen Zahl 6FE59.
Die im SDL-Diagramm von PING spezifizierte Ausgabe PRINT(N) wurde in der Abbildung fett herausgehoben, da es sich um die einzige explizite Ausgabe in der Logdatei handelt.
Auffällig ist, dass während des gesamten Testlaufes keine Timeouts erfolgten, und somit kein PING -Wert mehrfach verschickt werden musste. Da die Funkstrecke sehr kurz und die gewählte Timeout-Zeit mit drei Sekunden relativ lang gewählt wurde, konnte die Reaktion des PONG -Prozesses ohne Probleme immer zeitnah eintreffen, und der Timer deshalb immer rechtzeitig neu gestartet werden. Um auch die Transitionsfunktion TIMEOUTreceive zu verifizieren, müsste man den PONG -Prozess künstlich verzögern oder die übertragenen PONG -Signale absichtlich stören, auf beides wurde in diesem Testlauf jedoch verzichtet.
Die Adressierung der Netzwerk-Knoten ist für die Identifizierung von Sender und Empfänger in jeder Art von Netzwerk unumgänglich. Hierbei wird jedem Knoten mindestens eine, möglichst eindeutige Markierung in Form einer Zahl oder Zeichenkette zugeordnet. Über diese Adresse lässt sich dann der entsprechende Knoten innerhalb des Netzes ansprechen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4.1: Ein allgemeines Schichtenmodell für Netzwerkprotokolle
Ein wichtiger Punkt der Treiberentwicklung, besonders für die in dieser Arbeit primär betrachtete Ebene der MAC-Schicht, war somit der Entwurf eines geeigneten Adressierungs-Schemas, das den Anforderungen der hier betrachteten Netzwerke und Aufgabenstellungen in besonderem Maße Rechnung trägt. Dabei musste zwangsläufig die Adressierung in allen darüberliegenden Schichten bis hin zur Anwendung betrachtet werden, um ein effizientes Schema zu erhalten, welches sich auch in den folgenden Entwicklungsphasen, die ja alle auf der MAC-Schicht aufsetzen müssen, bewähren soll (siehe Abb. 4.1).
Aufgrund der Mobilität und des Fehlens einer statischen Infrastruktur sind komplizierte Adressumsetzungen per Broadcast (ARP) oder Server (DNS), wie sie zum Beispiel in LANs und im Internet benutzt werden, nur sehr begrenzt einsetzbar [16].
Für große, „flache“ Netzwerke ohne trennende Elemente wie Gateways und Router, wie sie ja gerade bei mobilen, drahtlosen Ad-Hoc-Netzwerken auftreten, sind die vorhandenen Möglichkeiten zur Definition von Hierarchien, beispielsweise Subnetze, unzureichend, da diese auf stationäre, lokal abgrenzbare Cluster von Knoten setzen.
Auch im Hinblick auf die Unterstützung von Gruppenkommunikation sind die herkömmlichen Schemata eher ungeeignet, da diese zum Beispiel keine ausreichenden Hierarchien innerhalb der Gruppen zulassen, also auch keine Untergruppen innerhalb von bestehenden Gruppen definiert werden können. Gerade diese Funktionalität wäre jedoch für Anwendungsgebiete wie den Katastrophenschutz oder das Militär äußerst sinnvoll, da diese bereits von sich aus hierarchische Strukturen nach Aufgabengebieten besitzen.
Bei der Verwendung des TCP/IP-Protokolls, wie es im Internet und in lokalen, auch drahtlosen, Netzen zur Zeit üblich ist, wird eine sehr komplexe Adressumsetzungs-Strategie benötigt (Abb. 4.2).
Die weit verbreiteten IP-Adressen sind für Menschen nur schwer zu merken und benötigen für den sinnvollen Einsatz daher ein Mapping eines lesbaren Domänen-Namens auf die entsprechende IP-Adresse des Empfängers. Dazu wird der angefragte Name zuerst an einen DNS-Server („Domain Name Service“) geschickt, welcher die gewünschte Adresse zurückliefert. Diese Umsetzung geschieht aufgrund der Struktur des Domänen-Namens und des DNS-Namensraums hierarchisch und verlangt oft mehrere Zugriffe auf verschiedene DNS-Server, um die Anfrage zu erfüllen. In der Praxis werden deshalb an vielen Stellen Caches verwendet, um dieses sehr aufwendige Verfahren zu beschleunigen.
Die Abbildung in den MAC-Adressraum benötigt wiederum ein spezielles Protokoll namens ARP („Address Resolution Protocol“), was den Overhead weiter vergrößert. Dazu wird die gefundene IP-Adresse an alle Knoten des anfragenden Netzabschnitts per Broadcast übermittelt, woraufhin der korrekte Knoten sich mit seiner MAC-Adresse an den Sender des ARP zurückmeldet. Diese Umsetzungsstrategie setzt jedoch einen aufwendigen Broadcast-Mechanismus und vor allem eine geeignete Abtrennung von Netzabschnitten vor, wie sie in Kabelnetzen mit Routern leicht möglich ist, da sonst alle Knoten des Netzes angefragt werden müssen.
Gerade in drahtlosen Netzwerken steigt die Wahrscheinlichkeit für ein Fehlschlagen der Adressumsetzung mit jeder eingeführten Ebene drastisch an, da es jederzeit zu einem Wegfall eines Mapping-Servers oder eines nicht erreichbaren Knotens bei einem Broadcast kommen kann. Wenn dann noch Mobilität der einzelnen Knoten möglich ist und die Netzwerke eine bestimmte Größe überschreiten, wird ein solch aufwendiger Auflösungs-Mechanismus in der Regel erfolglos sein.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4.2: Adressumsetzung im Internet
Eine einfache und sinnvolle Methode zur Vermeidung von Adressumsetzungen ist deshalb die Beschränkung auf nur eine Adressierungs-Ebene und die Benutzung logischer, menschenlesbarer Adressen, welche von der Anwendung bis hin zur MAC-Schicht unverändert bestehen. Genau dieser Ansatz wurde in dem hier entwickelten Adressierungsschema verfolgt und umgesetzt. Dadurch entstehen jedoch auch einige neue Probleme, die in Abschnitt 4.5 diskutiert werden.
Hierarchische Adressräume sind flachen Adressräumen in großen Netzen in jedem Fall vorzuziehen, da sie eine logische oder auch geographische Strukturierung des Netzes zulassen. Auch hier lassen sich IP-Adressen als Beispiel verwenden, bei ihnen existieren hierarchische Ansätze auf mehreren Ebenen.
Auf der Anwendungsebene befinden sich die bereits in 4.1 erwähnten Domänen-Namen. Diese besitzen einen hierarchischen Aufbau der Form level1.level2. … .leveln, wobei level1 das untere Ende und leveln die Wurzel der Hierarchie beschreibt („Top-Level-Domain“). Der Namensraum ist einerseits geographisch gegliedert, andererseits gibt es auch die Möglichkeit einer generischen Gliederung nach Aufgabengebieten. Abbildung 4.3 zeigt einen kleinen Auszug aus diesem Namensraum.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4.3: Auszug des DNS-Namensraums
In der Netzwerk-Schicht werden IP-Adressen verwendet. Diese lassen sich mittels Subnetzen nur in eine zweistufige Hierarchie, nämlich „Netzwerk“ und „Host“, bringen. Dieses Konzept lässt sich zwar durch die Verwendung von Routern sehr effektiv nutzen und ist dort auch ausreichend, für Ad-Hoc-Netzwerke ist es jedoch ungeeignet. Die MAC-Adressen im Ethernet bilden dagegen einen vollkommen flachen Adressraum ohne jegliche Hierarchie.
Nach diesen Betrachtungen eignen sich die Namen des DNS sehr wohl als Vorlage für ein hierarchisches Adress-Schema, wenn auch mit Einschränkungen. Geographische Strukturen sind in mobilen Netzen nur sehr begrenzt verwendbar, aber mit der so genannten generischen Gliederung nach Aufgaben oder Rollen lässt sich eine sinnvolle Systematik aufbauen, zum Beispiel Feuerwehrleute als Teil eines Trupps oder Studenten als Teil einer Universität.
Auch ist die Reihenfolge der Subdomains in einem Domänen-Namen nicht intuitiv, eher die umgekehrte Reihenfolge „vom Großen zum Kleinen“. Gültige Beispiele für solche Adressen wären somit „Feuerwehr.Löschtrupp1.Einsatzleiter“ und „Universität.Student.Mustermann“.
Dieser Aufbau eignet sich hervorragend für eine Erweiterung auf den Einsatz in der Gruppenkommunikation, sowohl syntaktisch als auch semantisch, wie in Abschnitt 4.3 vertieft dargestellt wird.
Die bekannten Adressierungsschemata, wie sie vorwiegend im Internet eingesetzt werden, eignen sich alle nur sehr bedingt für die Darstellung von Gruppenstrukturen. Insbesondere hierarchische Gruppen blieben bisher weitgehend unberücksichtigt.
Wie bereits in Abschnitt 4.2 erwähnt, ist es sinnvoll, eine Gliederung nach Aufgaben oder Rollen zu verwenden. Wenn man für diese Gliederung Gruppen einsetzt, welche sich auch noch hierarchisch anordnen lassen, hat man einerseits eine sinnvolle Strukturierungsmöglichkeit geschaffen, andererseits schon die Basis für Gruppenkommunikation gelegt.
Dieses „Hierarchische Gruppenschema“ wird nun im Folgenden genauer erläutert.
Die Syntax der Adressen wurde schon in Abschnitt 4.2 kurz vorgestellt. Sie orientiert sich im wesentlichen am Aufbau der Domänen-Namen des DNS. Die einzelnen Elemente der Adresse werden durch Punkte abgetrennt. Zusätzlich ist ein spezielles Platzhalter-Symbol * anstatt eines beliebigen Elements erlaubt. Die komplette Syntaxdefinition ist in Abbildung 4.4 festgehalten.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4.4: Syntaxdefinition des „Hierarchischen Gruppenschemas“
Durch die Zuweisung von Adressen an einzelne Netzknoten werden diese implizit Gruppen zugeordnet. Damit entfallen aufwendige Gruppenverwaltungen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4.5: Fünf Netzknoten mit Adressen
Sobald einem Knoten eine Adresse zugewiesen wurde, ist dieser automatisch Teil einer Pseudogruppe, welche alle Knoten des Netzes umfasst. Abbildung 4.5 zeigt fünf Knoten mit Adressen, welche damit alle Mitglieder dieser Pseudogruppe sind.
[...]
Kommentare