Service Discovery Protokolle für mobile Ad-Hoc Netze

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. O. Spaniol Seminar zur Datenkommunikation und verteilten Systemen im SS 2002 Service Discovery Protokolle für mobile Ad-Hoc Netze Mengrong Yu Betreuer: Mesut Günes 10. Mai

2 Gliederung 1. Einleitung 2. Mobile Ad-Hoc Netze (MANET) 2.1 Was ist ein mobiles Ad-Hoc Netz? 2.2 Service Discovery in mobilen Ad-Hoc Netzen 3. Service Discovery Protokolle 3.1 Service Location Protocol (SLP) 3.2 Jini 3.3 Universal Plug and Play (UPnP) 3.4 Salutation 3.5 Vergleich von SLP, Jini, Salutation und UPnP 3.6 Implementierung von SLP 3.7 Brückenaufbau zwischen verschiedenen Service Discovery Protokollen 4. Zusammenfassung Literaturverzeichnis 2

3 1. Einleitung Mobile Geräte und deren dynamische Verbindung stellen eine neue Form der Vernetzungstechnologie dar: unverwaltetes Netzwerk, dynamische Gerätevernetzung, besonders bei mobilen Geräten, die sich immer spontan und nicht voraussehbar in ein Netzwerk einwählen und ein Netz verlassen können. Die Anzahl der Ad-Hoc und Peer-to-Peer Netzwerke für Haushalt, Fahrzeug und mobiles e- Business ist in letzter Zeit rasant angestiegen. In so einer dynamischen Umgebung ein bestimmtes Gerät und einen bestimmten Service zu finden, ist eine wichtige Herausforderung an die Vernetzung und das Netzwerk. Bei den traditionellen Netzwerken sind fast alle Komponenten statisch. Im Gegensatz dazu können sich Geräte und Dienste in einem Ad-Hoc Netzwerk ständig bewegen und ändern. Solche Netzwerke brauchen immer eine Funktion, um sich selbst konfigurieren zu können. Geräte und Dienste müssen in der Lage sein, sich drahtlos in ein Netz einzuwählen, ihre Existenz bekannt zu geben und gleichzeitig andere Geräte und Dienste entdecken zu können. Dieser Prozess ist der sogenannte Service Discovery. Um einen erfolgreichen Service Discovery in einem Ad-Hoc Netzwerk ermöglichen zu können, muss ein Mechanismus für das dynamische Entdecken der verfügbaren Dienste in einem MANET und für das Sammeln der notwendigen aktuellen Informationen vorhanden sein. Dazu wird das Service Discovery Protokoll gebraucht. In dieser Ausarbeitung werden Service Discovery und einige bekannte Service Discovery Protokolle für Ad-Hoc Netze dargestellt. Im Abschnitt 2 wird ein Überblick über mobile Ad- Hoc Netzwerke und Service Discovery gegeben. Nachdem im dritten Kapitel die allgemeinen Aspekte von vier bekannten Service Discovery Protokollen diskutiert werden, werden sie anschließend unter verschiedenen Perspektiven miteinander verglichen. Außerdem wird in diesem Kapitel noch eine SLP Implementierung als Beispiel erläutert, um zu zeigen, wie überhaupt ein Service Discovery Prozess abläuft. Darüber hinaus werden Bedeutung und Wichtigkeit des Brückenaufbaus zwischen verschiedenen Protokollen behandelt. Im abschließenden vierten Kapitel erfolgt eine Zusammenfassung der Arbeit. 2. Mobile Ad-Hoc Netze (MANET) 2.1 Was ist ein mobiles Ad-Hoc Netz? Mobile Ad-Hoc Netze [15] sind drahtlose multihop Netze, die keine Kommunikationsinfrastrukturen, wie Basisstationen benötigen, wie z.b. bei der Kommunikation zwischen mobilen Geräten ( Handy, Notebooks usw.). Mobile Ad-Hoc Netzwerktechnologie ermöglicht ein autonomes System für mobile Knoten. Die Kommunikation in MANETs kann man in zwei Klassen (siehe Bild 1) unterteilen: Singlehop: zwei Knoten, die sich in ihrer Reichweite befinden, können direkt miteinander kommunizieren. Multihop: zwei Knoten, die sich nicht in der Reichweite befinden, können durch Zwischenknoten ihre Daten übertragen. Diese Unterteilung hängt von der geographischen Lage und der physikalischen Erreichbarkeit der Knoten ab. 3

4 Zur Zeit stehen aber hauptsächlich Mobile und Multihops vom MANET im Vordergrund. Mobile Jeder Knoten in einem Netzwerk besteht aus einem Router mit verschiedenen Schnittstellen und einigen IP-adressierbaren Hosts. Ein Festnetz, z.b. Internet oder ein Kommunikationsnetzwerk, besitzt immer eine feste Infrastruktur, die aus festen Routern und festen Hosts besteht. Die Datenübertragungen in diesem Fall werden über Drahtleitungen durchgeführt. Die Endgeräte, wie Hostcomputer oder Telefongerät sind immer an einer bestimmten Position angebracht. Deswegen kann man Endgeräte bzgl. deren Positionen immer schnell und gut in einem Netzwerk adressieren und identifizieren. Im nächsten Schritt stellt man sich vor, dass die Endgeräte mobil sind, d. h. ein Endgerät kann seinen Verbindungspunkt zu einer festen Infrastruktur immer ändern. Ein gutes Beispiel dafür ist das Mobiltelefon. Der Benutzer kann sich nomadisch bewegen. Aber egal wo er hingeht, er kann nur über eine Basisstation erst mit anderen Endgeräten in Kontakt treten. In diesem Fall ist das Endgerät mobil, während die Router im Netzwerk eine feste Struktur bilden. Im Vergleich zum zweiten Fall ist das Ad-Hoc Netzwerk mobil und dynamisch. In MANETs bewegen sich nicht nur Endgeräte ständig, sondern auch die Router selbst, d. h. ein mobiler Knoten in einem MANET besteht aus einem mobilen Router und einem mobilen Host. Daher ist die ganze Netzwerktopologie ebenfalls dynamisch. 4

5 Multihop Ein mobiles Netzwerk kann in zwei Schichten [17] unterteilt werden: die Mobile Host Schicht und die Mobile Router Schicht. Die Mobile Host Schicht besteht aus den Hosts, die vorübergehend an einem Festnetz oder einem festen Router anhängen sollen. Solcher Host braucht nur einen Singlehop zu einem festen Router. Die Mobile Router Schicht, auch die MANET Technologie, besteht aus mobilen Routern und mobilen Hosts. Parallel zu einer festen Infrastruktur bildet die Mobile Router Schicht eine dynamische Infrastruktur. Die Kommunikation zwischen zwei Knoten im MANET kann meistens nur durch Multihop erst stattfinden. Eine anschauliche Erklärung über mobile und Multihop in Festnetz und MANET sieht man im Bild 2. In einem MANET existiert kein Knoten, der immer erreichbar und adressierbar ist, weil jeder Knoten sich jederzeit beliebig bewegen kann. Daher ist es immer sehr schwierig, ein bestimmtes Gerät und einen bestimmten Dienst in einem mobilen Netzwerk zu entdecken und zu finden. Man kann nicht einfach die Position von einem Knoten feststellen, wie in einem traditionellen festen Netzwerk. Um dieses Problem zu lösen, wurden Service Discovery und Service Discovery Protokolle für MANET seit einiger Zeit erforscht und entwickelt. Mit solchen Protokollen ist das dynamische Entdecken von Diensten und Geräten in einem mobilen Netzwerk sowie die automatische Systemkonfiguration möglich. Außerdem ermöglichen solche Protokolle die Geräte und Dienste, sich selbst in einem MANET anzumelden und zu registrieren. Daher ist dynamisches Hinzufügen und Entfernen der Geräte und Dienste ohne weiteres auch vorstellbar geworden. Im folgenden wird dieses Thema noch vertieft. 5

6 2.2 Service Discovery in mobilen Ad-Hoc Netzen Service Discovery [1] bedeutet, dass ein Prozess in einem Netz automatisch einen gewünschten Dienst entdecken kann. Die Dienste können sich selbst auch bei einem Netz anmelden und registrieren. Für den Benutzer ist es sehr wichtig, bezüglich einer bestimmten Aufgabe, effektiv einen Dienst zu nutzen, ohne sein System neu konfigurieren zu müssen. Insbesondere mit der weitverbreitenden Entwicklung von mobilen Geräten und selbst verwaltenden Ad-Hoc Netzen wird das dynamische Entdecken von Diensten und Geräten in einem Netzwerk sowie die automatische Systemkonfiguration eine immer wichtigere Rolle spielen. Konstruieren wir nun folgendes Szenario: Ein Journalist will einen Report über ein Sportereignis in einem fremden Ort anfertigen. Er hat nur ein Notebook dabei, das eigentlich für das Schreiben und Drucken von Artikeln, für die Internetrecherche und für das Senden von s gedacht ist. Jetzt trifft dieser Journalist auf ein Problem. Wenn keiner ihm den Namen und Typ des Druckers verraten hat und kein entsprechender Druckertreiber auf seinem Notebook installiert ist, kann er nichts ausdrucken. Für ihn ist auch ein Internetzugang wegen ungültiger IP-Adresse und Submaske, Default Route und DNS-Server nicht mehr möglich. In dieser ungünstigen Situation würde der Service Discovery ihm helfen, einen Dienst zu entdecken, ein Gerät auszusuchen und zu nutzen. Zu betonen ist, dass mobile Geräte in Ad-Hoc Netzen selbst auch Dienste exportieren können. Ein Notebook kann beispielweise Übersetzungsdienste für Mobiltelefone anbieten, andererseits können Mobiltelefone eine Web Search mit Hilfe ihrer GPRS (General Packet Radios Service) durchführen. 3. Service Discovery Protokolle Service Discovery Protokolle [1] stellen einen Mechanismus für das dynamische Entdecken der verfügbaren Dienste in einem Netz und für das Sammeln der notwendigen Informationen über Suchen und Browser des Dienstes Auswahl des richtigen Dienstes Benutzen des Dienstes zur Verfügung. Seit einigen Jahren beschäftigen sich Computer-Wissenschaftler mit dem Service Discovery und deren Protokollen. Viele verschiedene Protokolle sind noch in der Entwicklung. Aber einige der Protokolle sind mittlerweile schon sehr bekannt und weit verbreitet: Service Location Protocol (SLP) Jini Salutation Microsoft s Universal Plug and Play (UPnP) In den folgenden Abschnitten werden die Grundlagen der o. g. Protokolle sowie die Service Registration, Service Discovery und Service Anmeldung vorgestellt. 6

7 3.1 Service Location Protocol (SLP) Das Service Location Protocol [2] wurde von der IETF entwickelt und 1997 veröffentlicht. Die neueste Version ist die auf SLPv1 verbesserte SLPv2 [3]. SLP ist ein IETF Standard, der ein Gerüst für den automatischen Service Discovery im TCP/IP Netz bildet. Überblick über das Protokoll Die SLP Architektur besteht aus drei Komponenten: User Agents (UA) führen den Service Discovery aus. Das bezieht sich auf den Klienten. Service Agents (SA) melden deren Services mit Positionen und Eigenschaften am Netz an. Directory Agents (DA) sammeln Service-Adressen und -Informationen der SAs und beantworten dann die Service-Anfragen der UAs. Bevor ein Klient einen DA kontaktieren kann, muss er zuerst die Existenz des DA bestätigen. Dazu gibt es drei verschiedene Methoden für DA Entdeckung: statisch, aktiv und passiv. Mit dem statischen Entdecken erhalten SLP Agenten die Adresse des DA über DHCP (Dynamic Host Configuration Protocol [4]). DHCP Server, die vom Netz-Administrator konfiguriert sind, können DHCP Optionen benutzen, um die Adressen des DA als Hosts zu definieren. Die notwendigen DHCP-Optionen für SLP sind der Literatur [5] zu entnehmen. Bild 3 illustriert die aktive und die passive DA Entdeckungsmethode. Bei dem aktiven Discovery senden UAs und SAs Nachrichten mit Serviceinformationen an die SLP Multicast Gruppenadressen (z. B ). Sobald ein DA eine Nachricht bekommen hat, antwortet er sofort durch Unicast dem entsprechenden Agenten. 7

8 Im Fall des passiven Discovery senden DAs periodisch multicast Werbungen über deren Services an alle SAs und UAs. SAs und UAs werden auf diese Weise Adresse des DA herausfinden. Danach können UA oder SA durch Unicast den DA kontaktieren. Operationsmethode Es ist sehr wichtig zu wissen, dass der DA bei SLP nicht obligatorisch ist. SLP hat zwei Operationsmöglichkeiten: Wenn ein DA anwesend ist, sammelt er alle Serviceinformationen, die er von UAs und SAs durch Unicast bekommen hat (siehe Bild 4). Wenn ein DA abwesend ist, senden UAs wiederholt und multicast die gleiche Frage zu den SLP Multicast-Adressen. Sobald ein Dienst eines SA nachgefragt wurde, sendet dieser unicast die Antwort zum UA. Andererseits melden sich SAs auch periodisch bei allen SLP Multicast-Adressen, so dass die UAs immer neue Dienste kennen lernen können (siehe Bild 5). Tatsächlich wird der DA insbesondere in ein großes Netz mit vielen Services eingesetzt. Wenn ein DA anwesend ist, bekommt der UA natürlich eine schnellere Antwort. Gleichzeitig sind Multicast-Nachrichten teilweise oder ganz vermieden worden. Dementsprechend wird SLP ohne einen DA in kleinen Netzen bevorzugt. Servicebeschreibung Die Dienste sind durch eine Service URL und einen Service Template [6] beschrieben. Die URL enthält die Position von einem Service: IP-Adresse, Port Nummer und Path. Der Klient bekommt eine Service-URL, dann hat er alle Informationen, die er braucht, um sich mit einem gewünschten Dienst in Verbindung zu setzen. 8

9 Ein Service Template charakterisiert die Eigenschaft eines Services sowie dessen Default Wert. Ein Service Template mit einem Netzdrucker könnte wie folgt aussehen [1]: service:printer://lj4050.tum.de:1020/queue 1 scopes = tum,bmw,administrator printer-name = lj4050 printer-model = HP LJ4050 N printer-location = Room 0409 color-supported = false pages-per-minute = 9 sides-supported = one-sided, two-sided SLP ist ein IETF Standard für den Service Discovery und die automatische Konfiguration von Klienten. Es bietet eine Menge von dezentralisierten Operationen und kann sich von einem kleinen und unadministrierten Netzwerk zu einem großen Netz erweitern. Aber zu betonen ist, dass SLP hauptsächlich nur für Service Discovery in TCP/IP Netzwerken eingesetzt wird. 3.2 Jini Die Jini-Technologie [1,7] ist eine Erweiterung der Programmiersprache Java und wurde von Sun Microsystem entwickelt. Jini läuft nahezu unabhängig von der Plattform und stellt somit einen weiteren Meilenstein in der Zusammenfassung von isolierten Rechnern dar. Die kleinen Programme liegen an einer zentralen Stelle des Internets und können von Klienten geladen und ohne Installationsaufwand genutzt werden. Wie in anderen verteilten Systemen, werden die Teilnehmer an einem Jini-Netzwerk als Klienten und Server bezeichnet. Ein Server hat eine Schnittstelle, die kurz als Dienst oder Service bezeichnet wird. Und diese Schnittstelle ist sowohl dem Klienten als auch dem Server bekannt. Zu betonen ist, dass Jini komplett in Java implementiert ist. 9

10 Alle Klienten von einem Netz sollen in der Lage sein, einen Dienst in diesem Netz zu entdecken und zu benutzen. Um das zu realisieren, muss man zuerst folgende primäre Mechanismen [7] kennen lernen. Lookup-Service Der Lookup-Service stellt das Kernelement eines Jini-Netzwerkes dar. Er ist ein Vermittler zwischen Klienten und Servern. Sobald eine Hard- oder Software in einen Jini-Verband eintritt, muss sie sich an einer zentralen Stelle registrieren, dem Jini Lookup-Service. Dieser verwaltet in einer Tabelle alle angemeldeten Dienste und Services, sowie deren Eigenschaften. Wenn ein Klient einen Jini-Dienst (Service) nutzen möchte, meldet er sich bei dem Lookup- Service an. Der Lookup-Service sucht dann nach einem passenden Dienst, und liefert das Ergebnis in Form von Proxy-Objekten [7] an den Klienten zurück. In diesem Sinne ist also der Lookup-Service nichts anderes als ein Server, der den Anmelde-Dienst zur Verfügung stellt. Somit ist nun die Möglichkeit gegeben, dass der Klient ohne Umwege über den Jini- Lookup-Service mit dem dienstanbietenden Server kommunizieren und angebotene Methoden aufrufen kann. Discovery und Join Server und Klient können über den Lookup-Service in Verbindung treten. Jetzt ist nur die Frage, wie ein Server oder auch ein Klient überhaupt Kontakt zu dieser zentralen Registrierungseinheit aufnehmen kann. Eine Anmeldung beim Lookup-Service besteht aus zwei Schritten. Im ersten Schritt sucht der Service bzw. der Klient nach einem Lookup-Service, was mit Discovery bezeichnet wird. Wenn ein Dienstanbieter diesen gefunden hat, meldet er sich im zweiten Schritt über das Join-Protokoll an. Dafür lädt der neue Service ein Service-Register-Objekt aus dem Lookup- Service herunter und nimmt dann mit Remote Methode Invocation (RMI) [7] den Kontakt zum Lookup-Service auf. Der Server teilt dem Lookup-Service seine ID-Nummer und die Eigenschaft dieses Dienstes mit. Danach muss der Dienst noch ein Proxy-Objekt übergeben, damit der anfragende Klient direkt den Server kontaktieren kann. Leasing Nach der erfolgreichen Anmeldung müssen sich der Lookup-Service und der Dienstanbieter auf eine Leasingzeit einigen. Das ist eine Zeitspanne, in der sich der Server beim Lookup- Service immer wieder zurückmelden muss. So ist sichergestellt, dass sein Dienst weiterhin verfügbar ist. Der Leasing Manager von Jini gewährleistet die Stabilität eines Jini-Netzwerkes. Ein Leasing hat folgende Merkmale: o Es besteht die Möglichkeit, dass der Service das Leasing während seiner Laufzeit kündigen kann. o Der Service kann sein Leasing erneuern. Falls dies passiert ist, muss ein neues Leasing mit dem Lookup-Service wieder ausgehandelt werden. o Wenn ein Leasing abläuft, wird der Lookup-Service den Dienst aus seiner Liste löschen. Durch Leasing hat der Lookup-Service immer einen Überblick über alle, bei ihm registrierten und aktiven Dienste sowie Services. 10

11 Distributed Events Bei einem Java Programm besteht immer die Möglichkeit, dass sich Klassen und Methoden, die an bestimmten Ereignisveränderungen interessiert sind, in eine sogenannte Listener- Klasse [8] eintragen lassen. Für Jini wird diese Konzeptidee in Bild 6 dargestellt. Für Jini haben die Distributed Events eine besondere Bedeutung, da Jini für die Arbeit in nichtdeterministischen Umgebungen geschaffen wurde. Ein Vorteil bei diesem verteilten System ist, dass eine Anwendung die Möglichkeit hat, sich vom Lookup-Service informieren zu lassen, sobald eine gewisse Komponente zur Verfügung steht. Genauso besteht die Möglichkeit, eine Nachricht aus dem Lookup-Service zu erhalten, wenn eine Komponente den Jini-Verbund verlassen hat oder nicht mehr zur Verfügung steht. Transaktionen Bei Transaktionen handelt es sich um einen Mechanismus, der gewährleistet, dass die Dienstoperationen konsistent und komplett in einem Verbund sind. Eine Transaktion kann mehrere atomare Operationen umfassen, d.h. es ist kein Zwischenergebnis gespeichert worden. Alle Transaktionsbeteiligten müssen nachvollziehen können, ob eine Transaktion erfolgreich war oder nicht. Jini handhabt Transaktionen mit Hilfe eines Transaktionsmanagers. Dabei tun Dienste, die an einer Transaktion beteiligt sein können, dies durch Aufforderung zur Übergabe eines Transaktionsobjekts. Hierzu muss der Klient mit dem Transaktionsmanager kommunizieren. 11

12 Die Bestätigung der Transaktion folgt dem erfolgreichen Abschluss aller einzelnen Operationen. Dabei ist ein zweiphasiges Bestätigungsprotokoll bei allen Diensten, die an der Transaktion beteiligt sind, erforderlich. Erste Phase: Die Teilnehmer des Transaktionsprozesses sollen die hervorgerufenen Änderungen bestätigen. Somit ist garantiert, dass beispielweise bei einem Systemabsturz die Daten entweder bestätigt oder verworfen werden. Sobald ein Dienst diese Zusicherungsmaßnahmen nicht durchsetzt, verwirft der Transaktionsmanager die komplette Transaktion. Zweite Phase: wenn eine Transaktion von allen Teilnehmern bestätigt wurde, darf diese dann nicht mehr verworfen werden. Aber hierbei besteht noch ein anderes Problem: die Deadlocks. Ein Dienst weiß nicht, welche anderen Dienste auch an der Transaktion teilnehmen. So kann es also passieren, dass zwei Transaktionen die Daten des jeweils anderen sperren. Eine Lösung ist die Einführung von Timeouts. Dies bedeutet, dass die Transaktion doch automatisch verworfen wird, wenn sie nach dem Erreichen eines Timeouts immer noch nicht beendet ist. Oben wurde die Theorie, die hinter Jini steckt, kurz erläutert. Jini ist ein verteiltes System, welches eng mit Java verbunden ist. Da ist zum einen der Jini-Lookup-Service, der unter Java läuft, und zum anderen werden die verwendeten Dienste direkt oder indirekt (mit Hilfe von Proxies) mittels einer Java Virtual Machine ausgeführt. Ein Jini-Netzwerk kann man somit generell überall aufbauen, wo einzubauende Dienste zumindest eine Java Virtual Maschine (JVM) zur Verfügung stellen. 3.3 UPnP Der Universal Plug and Play [16] ist eine Architektur für das weit verbreitete Peer-to-Peer Netzwerk, das sowohl intelligente und drahtlose Geräte als auch verschiedene PCs verbindet. Er ist geeignet für die Ad-Hoc Netzwerke oder das verwaltungslose kleine Netzwerk, z. B. für zu Hause oder für den Zugang zum Internet. UPnP wurde für die Zero-Konfiguration entwickelt, d. h. die unsichtbare Vernetzung und der automatische Discovery für heterogene Geräte verschiedener Hersteller und Händler. Ein Gerät kann sich somit dynamisch mit einem Netz verbinden und bekommt dann eine IP- Adresse. Service und Gerät können ihre Fähigkeiten registrieren lassen und sich dabei über die anderen Geräte sowie deren Fähigkeiten informieren. DHCP und DNS Servers sind optional und werden nur dann verwendet, wenn sie im Netz erhältlich sind Was bedeutet eigentlich Universal bei UPnP? Universal heißt, dass hier kein Geräte- Treiber, aber ein gemeinsames Protokoll vorhanden ist. UPnP Vernetzung ist von Medien unabhängig. UPnP Geräte können durch alle Programmiersprachen implementiert sowie auf allen Betriebssystemen installiert werden. Ein Hersteller eines Betriebssystems kann selber die zu seinem Kunden passenden APIs konstruieren. Im Allgemeinen laufen Service Discovery und Vernetzung beim UPnP in folgenden 5 Schritten ab: 1. Discovery Will ein Gerät in ein Netz eintreten, erlaubt das UPnP Discovery Protocol den Geräten, sich multicast bei Control Points über deren Service im Netzwerk anzumelden. Jeder daran interessierte Control Point muss lauschen, welche neuen Fähigkeiten und welche neuen Services von Geräten erhältlich sind und welche Standard-Multicast-Adresse ein Gerät hat. 12

13 Analog dazu erlaubt das UPnP Discovery Protocol dem Control Point, nach dem gewünschten Gerät im Netz zu suchen, wenn ein Control Point sich zu einem Netzwerk einfügen lassen möchte. Der fundmentale Austausch zwischen o.g. zwei Fällen ist dann eine Discovery Message, die wenige, elementare Spezifikationen über die Geräte oder deren Service ( z. B. Type, Identifier oder einen Zeiger usw.) enthält. Z.B. im zweiten Fall schickt der Control Point multicast eine Discovery Message an alle Geräte. Alle Geräte müssen dann der Message gut zuhören und eine Antwort unicast zurückschicken, wenn das Suchkriterium der Geräte oder des Services in der Discovery Message erfüllt ist. So kann ein Control Point die Geräte, die an ihm interessiert sind, langsam kennen lernen. Dies wird in Bild 7 veranschaulicht. 2. Beschreibung Obwohl ein Control Point bereits ein Gerät oder einen Service gefunden hat, weiß er immer noch wenig über das Gerät und dessen Service. Dazu muss er noch weiter mit diesem Gerät kommunizieren. Er muss die genaue Beschreibung über dieses Gerät aus der URL holen, die das Gerät mit der Discovery Message geliefert hat (siehe Bild 8). Die Geräte selbst können auch wieder andere logische Geräte oder Dienste enthalten. Wie oben schon erwähnt, ist die UPnP Beschreibung für ein Gerät in XML deklariert. Diese Beschreibung enthält nicht nur die Information über Hersteller, Händler und die serielle Nummer, sondern auch genaue Informationen über den Dienst, den dieses Gerät anbieten kann. 3. Control Wenn der Control Point schon über genaue Informationen zum entsprechenden Gerät und seinen Dienst verfügt, sendet er eine Aktionsanforderung an den Dienst dieses Gerätes. Dazu kann er eine passende Control Message an die Control URL für einen Service schicken. 13

14 Dementsprechend liefert der Service ein Ergebnis oder eine Fehlermeldung von dieser Aktion zurück (siehe Bild 9). 14

15 Der UPnP kann keinen allgemeinen API für die Anmeldung spezifizieren, weil der Control Point nicht nur einen Service aufrufen, sondern auch den Wert der Zustandsvariable beim Aufruf ändern kann. 4. Eventing Der Service muss dem Control Point mitteilen, wenn sich eine Variable im Service geändert hat. Dann ist das Serivce verpflichtet, den aktuellen Zustand über die Variablen durch Even Message multicast zu veröffentlichen. Diese Message ist ebenfalls mit XML beschrieben und durch die General Even Notification Architektur (GENA) [10] formalisiert. 5. Präsentation Der fünfte Schritt ist eine Ergänzung zu den Schritten drei und vier. Nach den Schritten eins und zwei kann der Control Point mit der Präsentation beginnen. Wenn ein Gerät eine URL für die Präsentation hat, kann es dann eine Seite von der URL holen und anschließend auf den Browser herunterladen. Damit kann ein Benutzer den aktuellen Stand eines Gerätes kontrollieren. 3.4 Salutation Salutation [11,14] ist ein weiteres Netzwerk-Koordinationsprodukt für den Service Discovery. Die Salutation Architektur ist von einem Industrienkonsortium entwickelt worden. Dieses versucht seit jeher, einen Mittelweg zwischen dem dienstbetonenden UPnP und Jini zu gehen. Salutation hat folgende fünf wichtige Eigenschaften, die für das Ad-Hoc Netz sehr gut geeignet sind. a) Service, Registry and Discovery Bei Salutation gibt es mehrere, sogenannte Salutation Manager (SLMs) [9,12], die eine Funktion als Service Makler haben. Der SLM bietet eine vom Transport unabhängige Schnittstelle zu Klienten und Servern, die auch SLM API (Salutation Manager Application Programm Interface) genannt wird. Wenn ein Service in das Netzwerk eintreten möchte, muss er sich zuerst bei SLM anmelden und registrieren. Ein SLM kann entweder am direkten Zugang oder in näherer Umgebung entdeckt werden, d.h. dieser Manager versucht, als Agenten für seine Dienste zu agieren und andere SLMs in seiner Umgebung zu finden. Damit können die SLMs die Registrierungsinformationen über ihre Dienste miteinander austauschen. Diese Interaktionsprozesse zwischen SLMs werden durch den sogenannte Salutation Manager Kommunikationsprotokoll definiert. Wenn ein Klient nach einem Service oder einem Dienst fragt, schickt er die Nachfrage an einen lokalen SLM, der dann wieder mit den anderen SLMs koordinierend arbeitet. Sobald ein gewünschter Service gefunden ist, wird das Ergebnis an den Klienten zurückgeliefert. Die Nutzung des Services ist auch durch SLM geregelt (siehe Bild 10). Jeder Salutation Manager hat eine universelle Nummer zur Identifizierung, die sogenannte SLM-ID. Diese SLM-ID wird überall von Klienten, Service und Salutation Manager verwendet, um einen teilnehmenden SLM auf einer vom Transport unabhängigen Weise zu identifizieren. Die Unabhängigkeit vom Transport ist eine sehr wichtige Eigenschaft von Salutation. 15

16 b) Unabhängigkeit vom Transport und Betriebssystem Salutation hat einen Transport Manager, der den Salutation Manager vom Transport unabhängig macht. Ein Salutation Manager kann mit einem oder mehreren Transport Managern arbeiten. Jeder Transport Manager entdeckt wieder andere bewegliche Salutation Manager, die über ihn Daten transportieren möchten. Dann registriert der Transport Manager die entdeckten SLMs und deren SLM-ID auf seinem lokalen Salutation Manager. Bei Salutation sind Salutation Manager und Transport Manager voneinander getrennt. So eine Struktur erlaubt, dass der Salutation Manager unabhängig vom Betriebsystem ist. c) Availbility Checking Der Salutation Manager kann periodisch checken, ob alle Dienste noch erhältlich und aktuell sind. Der lokale Salutation Manager schickt periodisch eine Nachricht an andere Salutation Manager in der näheren Umgebung, um ein Availability Check durchzusetzen. d) Session Management Wenn ein Klient einen Service nutzen möchte, baut der Salutation Manager eine virtuelle Datenübertragungsleitung zwischen Klienten und Service auf. Dieser Prozess heißt Service Session [9]. Kommandos und Daten werden als Messages auf dieser Leitung ausgetauscht. Messages müssen ein vordefiniertes Format haben und können dann erst unter einem vordefinierten Protokoll transportiert werden. Die Verwaltung über Messagestrom und Datenformatdefinition wird vom Salutation Manager übernommen. Das ist die sogenannte Salutation Personality [9]. Dadurch wird ein gemeinsames Übertragungsprotokoll und ein gemeinsames Datenformat zwischen einem Klienten und einem entdeckten Service definiert. 16

17 e) Object Locate and Load Salutation kann einen Service anbieten, der Doc Storage [9] genannt wird. Der Doc Storage Service enthält Seitenangabe, Gerätetreiber, Anmeldungsprogramme und Anmeldungsdaten. Der Doc Storage wird wiederum durch ein Filetyp und die Eigenschaft des Datentyps identifiziert. Z. B. ein Klient hat einen von ihm gewünschten Drucker entdeckt. Leider hat er keinen Gerätetreiber dabei. Dann kann der Klient Salutation nutzen, um den Doc Storage Service, der den entsprechenden Treiber enthält, zu finden. Sobald der Klient den passenden Doc Storage Service positioniert hat, kann er schon die Inhalte erkennen (hier Drucker- Treiber) und anschließend die Installation durchführen. Nach der Nutzung des Services- Inhaltes kann der Klient sie wieder deinstallieren und zurückgeben. Die Inhalte des Doc Storage sind nicht begrenzt. Ein Drucker kann z. B. einige Doc Storage Services haben, jeder davon enthält wiederum unterschiedliche Gerätetreiber, die verschiedene Betriebssysteme unterstützten. Deswegen kann ein auf Java basierter Klient Salutation s Kommandos benutzen, um den vom Java Proxy Objekt unterstützten Drucker zu positionieren und zu laden. 3.5 Vergleich von SLP, Jini, Salutation und UPnP Im vorigen Kapitel wurden die Arbeitsweise und die Grundlagen der einzelnen Protokolle erläutert. Nun sollen die vier Protokolle aus verschiedenen Perspektiven miteinander verglichen werden. SLP Dieses Service Location Protokoll ist schon standardisiert und sehr gut von IETF dokumentiert worden. SLP hat nicht nur einige Referenzimplementierungen, sondern bereits kommerzielle Produkte auf dem Markt. SLP hat eine sehr flexible Struktur. Gleichzeitig macht der Service Template den Service Browsing und die Kommunikation zwischen Menschen möglich. Weil SLP mit oder ohne DA arbeiten kann, ist dieses Protokoll für Netzwerke verschiedener Größe sehr geeignet. SLP kann genutzt werden, um eine sehr kleine Ad-Hoc Verbindung zu einem großen Unternehmensnetzwerk zu erweitern. SLP enthält auch ein Leasing-Konzept mit einer Lifetime, die definiert, wie lange ein DA eine Serviceregistration behalten kann. Während Jini von Java abhängig ist, bleibt SLP unabhängig von irgendeiner Programmiersprache. SLP wurde durch ein offenes und von Händlern unabhängiges Forum entwickelt. Seine Implementierungen sind von daher frei verfügbar. Jini Jini ist ein relativ neuer Ansatz. Bis jetzt gibt es leider noch kein Produkt auf dem Markt. Ein großer Unterschied zu anderen Service Discovery Protokollen ist, dass Jini auf der Programmiersprache Java basiert. Das macht Jini aber unabhängig von der Plattform und dem Betriebssystem. Sehr wichtig ist, dass Jini Java Remote Method Invocation (Java RMI) Protokolle benutzt, um die Programme aufzurufen. Das ist auch der große Vorteil von Jini gegenüber anderen nicht auf Java basierenden Service Discovery Protokollen. Ein weiterer Schwerpunkt von Jini liegt darin, aufgebautes Netz so stabil und flexibel wie möglich zu halten. Ein Hinzufügen und Entfernen von Diensten ist ohne weiteres möglich, da dies durch das Leasing-Konzept ermöglicht wird. Das ist besonders nützlich für das Ad-Hoc Netzwerk. 17

18 Ein Nachteil von Jini ist, dass seine Geräte unbedingt eine JVM besitzen müssen, weil Jini stark von der Programmierumgebung abhängig ist. Das führt für den Treiber eines großen Gerätes zu einer großen Hardwareanforderung, was allerdings nicht immer erfüllbar ist. Salutation Salutation kann in Java implementiert werden, aber auch in anderen Programmiersprachen. Also ist Salutation von der Programmiersprache unabhängig. Während sowohl bei SLP und Jini, als auch bei UPnP der Datentransport auf TCP/IP zurückzuführen ist, ist dieser bei Salutation unabhängig davon. Er geschieht durch die Transport Manager, die sich in die Netzwerkarchitektur einschalten. Weiterhin ist zu betonen, dass Salutation auf Windows TM, Windows CE TM, VxWorks, Tornado und Java TM Systemen bereits erfolgreich implementiert worden ist. Die Implementierung auf anderen Plattformen wird in naher Zukunft entwickelt und durchgeführt. UPnP Universal Plug and Play ist ein sehr neues Service Discovery Protokoll. Es befindet sich noch in einer frühen Entwicklungsphase. UPnP ist nur für die TCP/IP Netzwerke konstruiert worden. Zum Senden und Empfangen von Nachrichten werden Daten in HTML-Dateien eingebettet und über HTTP verschickt. Die Beschreibung des Services wird durch eine XML-Datei gemacht. Bei UPnP ist das Suchen nach den Service-Eigenschaften immer noch nicht möglich, auch nicht bei der neuesten Version. UPnP besitzt keinen sogenannten Directory-Service. Dessen Kommunikation ist über das Simple Service Discovery Protocol (SSDP) möglich. Wie bei den meisten Protokollen ist UPnP unabhängig von der Programmiersprache. Bis jetzt gibt es noch keine Implementierung auf irgendeiner Plattform von UPnP. Aber Microsoft plant, es auf Windows zu implementieren. Die Tabelle 11 (siehe Seite 19) gilt als eine kleine Zusammenfassung der bisherigen Erläuterungen. 3.6 SLP Implementierung Die Basisfunktionen von SLPv2 sind in ANSI C implementiert, und dabei werden UDP Sockets verwendet. Das Ziel der Implementierung liegt darin, eine Service Discovery Aktion zu demonstrieren. Man implementiert zwei verschiedene Architekturen -mit und ohne DAund mit Überwachungstools. Architektur mit DA Der Service Agent SA ist mit einem Service Template konfiguriert, der in einem Text File gespeichert ist. Der Template enthält die Service URL, das Scope und die Eigenschaften des Services. Sobald ein SA gestartet ist, fängt er an, einen aktiven DA zu suchen und zu positionieren. Wenn er eine Antwort vom DA bekommen hat, kann er die IP-Adresse des DA herausfinden. Dann sendet er eine Service Registration Message zum DA. Wenn er eine Service Ack Mesage vom DA erhalten hat, wird SA terminiert. 18

19 Feature SLP Jini Salutation UPnP Developer IETF Sun Salutation Microsoft Microsystems Consortium License open source open license, but open source open (only for fee for members) commercial use Version Network transport TCP/IP independent independent TCP/IP Programminglanguage independent Java independent independent OS und Platform dependent independent dependent independent Code mobility no yes (Java RMI) no no Srv attributes yes yes yes no searchable Central cache yes (optional) optional using yes (optional) no repository SLP Leasing concept yes yes no yes Security IP dependent Java based authentication IP dependent Tabelle 11: Vergleich von SLP, Jini, Salutation und UPnP Gleichzeitig gibt der DA seine Existenz durch IP multicast zum Starten bekannt. Dann ist der DA bereit, Service Registrations vom SAs und Service Requests von UAs sowie eine Antwortnachricht für ein aktives DA Discovery zu verarbeiten. Wenn DA eine Service Registration Nachricht bekommt, fügt er diese Service zu seiner Datenbank hinzu und sendet dem SA eine Service Ack -Nachricht zurück. Der User Agent UA muss zuerst mit der Eigenschaft des Services, den er sich wünscht, initialisiert werden. Die Eigenschaften des Services enthalten z. B. Service Type, Scope und optionale gewünschte Eigenschaften. Das wird über Command Line Options gemacht. Ein Beispiel: ua service : printer: tum color=true fragt alle Farbdrucker Services im Scope tum. Außerdem verwendet UA zwei Operationsprozeduren. Bei der Operation 1 wird ein Service Request abgeschickt, während bei Operation 2 ein Attribute Reguest gesendet wird, die alle Eigenschaften des gewünschten Services als Ausgabe zurück gibt. Die Operation 1 ist hauptsächlich für die Servicesuche gedacht. Die Operation 2 ist stattdessen eine Basis für das Service Browsing. Der UA terminiert, wenn er entweder ein Service Reply oder ein Attribute Reply bekommt. Architektur ohne DA Die User und Service Agenten werden in dieser Architektur als mini- UA und mini-sa bezeichnet. Der mini-sa registriert seine Dienste nicht mit einem Directory, sondern durch IP Multicast. Wenn der SA ein Service Reguest oder ein Attribute Request bekommt, beginnt er mit der Suche in seinem Service Template. Sobald er etwas gefunden hat, antwortet er dem mini-sa. Die Arbeitsweise von UA in dieser Architektur ist sehr ähnlich der Architektur mit DA, bis auf einen Unterschied, dass mini-ua ganze Zeit den Multicast-Nachrichten von SAs gut zuhören und lauschen muss. 19

20 SLP Monitoring Tools Bis jetzt sind zwei Überwachungstools entwickelt worden, die dabei helfen können, die SLP Protokolltransaktionen besser zu verstehen. Der slp_listener gehören zur SLP Multicast-Gruppe und geben alle SLP Nachrichten aus. Der slp_talker generiert SLPv2 Nachrichten und sendet sie danach zu der IP-Adresse eines bestimmten Hosts oder zu der SLP IP Multicast-Gruppe. 3.7 Brückenaufbau zwischen verschiedenen Service Discovery Protokollen Oben wurden einige oft erwähnte Service Discovery Protokolle dargestellt. In der Wirklichkeit gibt es noch viel mehr solcher Protokolle, die entweder schon entwickelt wurden oder noch in der Entwicklung sind. So eine große Zahl von Protokollen führt zu der Überlegung, ob zwischen verschiedenen Service Discovery Methoden und zwischen Geräten mit unterschiedlichen Service Discovery Protokollen eine Brücke gebaut werden kann, d. h, ob man z. B. mit einem Salutation Gerät einen SLP Drucker entdecken kann. Diese Überlegung und dieser Ansatz erregen immer größeres Interesse und Aufmerksamkeit bei Computerwissenschaftlern. Bis jetzt sind folgende Mappings schon entwickelt worden: Mapping vom SLP und Salutation zu Bluetooth SDP [12]. Discovery der proxied Jini Geräte über SLP [13]. Emulate der Jini Funktionen über Salutation-Lite [14]. Mapping zwischen Salutation und SLP Zusammenfassung Service Discovery wird in der Zukunft immer mehr an Bedeutung gewinnen, besonders bei mobilen Ad-Hoc Netzen. Weil in MANETs alle Knoten mobil sind, ändert sich die Netzwerktopologie auch ständig. So muss das gesamte Netzwerk mit dem eingesetzten Verfahren zurecht kommen. Außerdem existieren in einem MANET keine Knoten, die immer erreichbar sind. Daher muss sich der Arbeitsmechanismus für ein MANET einen besonderen Anspruch stellen. Mit Service Discovery Protokollen kann jedes Gerät in einem mobilen Ad-Hoc Netz automatisch einen Dienst mit Eigenschaften, die ein Netz anbieten kann, entdecken. Darüber hinaus können auch verschiedene Dienste sich selbst auf dynamische Weise im Netz anmelden. So kann jeder Benutzer problemlos herausfinden, wo und wie er in einem Netz zu seinen Gunsten einen gewünschten Dienst bekommen und benutzen kann. In dieser Arbeit wurden einige wichtige Service Discovery Protokolle beschrieben. Danach wurden SLP, Jini, Salutation, und UPnP aus verschiedenen Perspektiven miteinander verglichen. SLP ist schon standardisiert und sehr gut von IETF dokumentiert worden. SLP hat nicht nur einige Referenzimplementierungen, sondern bereits kommerzielle Produkte auf dem Markt. Jini ist ein relativ neuer Ansatz. Bis jetzt gibt es leider noch kein Produkt auf dem Markt. Ein großer Unterschied zu anderen Service Discovery Protokollen ist, dass Jini auf der Programmiersprache Java basiert. Das macht Jini unabhängig von der Plattform und dem Betriebssystem. UPnP ist ein sehr neues Service Discovery Protokoll. Es befindet sich noch in 20

21 einer frühen Entwicklungsphase. Zu betonen ist, dass UPnP nur für die TCP/IP Netzwerke konstruiert worden ist. Während sowohl bei SLP und Jini, als auch bei UPnP der Datentransport auf TCP/IP zurückzuführen ist, ist dieser bei Salutation unabhängig davon. Er geschieht durch die Transport Managern, die sich in die Netzwerkarchitektur einschalten. Außer den Protokollen, die in dieser Ausarbeitung dargestellt sind, sind noch viele weitere Protokolle in der Entwicklung. Es ist zu erwarten, dass zukünftig noch mehr Service Discovery Protokolle entwickelt und implementiert werden. Daher ist es sehr wichtig, eine Brücke zwischen verschiedenen Service Discovery Protokollen aufzubauen. Damit kann Service Discovery trotz unterschiedlicher Geräte und Dienste, die unter verschiedenen Service Discovery Protokollen stehen, erfolgreich stattfinden. Literatur [1] Christian Bettstetter and Christoph Renner. A Comparision of Service Discovery Protocols and Implementation of the Service Location Protocol. [2] Erik Guttman. Service Location Protocol: Automatic Discovery of IP Network Services. IEEE Internet Computing, 3(4): 71-80, Juli. [3] Erik Guttman, Charles E. Perkins and Micheal Day. Service Location Protocol, Version2. Internet RFC 2608, June [4] Dr. Dromes. Dynamic Host Configuration Protocol. IETF, RFC 2131, March [5] Charles E. Perkins and Erik Guttman. DHCP Options for Service Location Protocol. Internet RFC 2610, June [6] E. Guttman, C. Perkins and J. Kempt. Service Templates and Service: Schemes. IETF, RFC 2609, June [7] Sun. Technical White Paper: Jini Architectural Overview. [8] Jan Newmarch. Jan Newmarch s Guide to JINI Technologies, [9] Brent A. Miller and Robert A. Pascoe. Salutation Service Discovery in Pervasive Computing Environments. [10] [11] Rekesh John. UpnP, Jini and Salutation, CSWL,1999. [12] Brent Miller. Mapping Salutation Architecture APIs to Bluetooth Service Discovery Layer Version 1.0. [13] Manfred Bathlet und Jochen Nickles. Das Plug und Play der Automatisierung. Elektronik (Volume 6), Pages 54-62, March [14] Robert A. Pascoe. The Salutation Consortium Newsletter. April [15] Mobile Ad-hoc Networks Mobile Ad-hoc Netzen (MANET). 21

22 http: //fakir.informatik.rwth-aachen.de/manet, [16] Universal Plug and Play Device Architecture, Version 1.0, [17] M. Scott Corson, Jesoph P. Macker and Gregory H. Cirincione. Internet-based Mobile Ad Hoc Networking. IEEE Internet Computing: 63 70,