Softwareentwicklung in verteilten Umgebungen, Teil 6 Discovery (Coulouris et al., Kapitel 16) Dieter Schmalstieg
Ubiquitous Computing Idee: Physische Umgebung mit eingebetteten Diensten Verknüpfung stationäre-mobile Geräte Verknüpfung mobile-mobile Geräte Physische Mobilität Geräte kommen und gehen Logische Mobilität Geräte ändern Kommunikationspartner Software muss häufige Änderungen verkraften
Association (Verknüpfung) Association = logische Geräte-Beziehung Association ist keine aktive Netz-Verbindung Kriterien für Association Skalierbarkeit: Welche(r) der 1000 Sensoren? Scope (Bereich): Drucker im aktuellen Stockwerk gewünscht Authorisierung ( Zugriff auf meine Handy-Fotos? ) Netzwerk Bootstrapping Erster Schritt der Association Auffinden von Addresse oder Name E.g. ZeroConf, Bonjour
Zweck Discovery Services (1/2) Einstiegspunkt in Ad-hoc Networken Knoten verschwinden und tauchen an anderen Orten wieder auf Discovery kommt vor Association (=Service Selection) Prinzipien Knoten kann Existenz und Dienste ankündigen Anderer Knoten kann Existenz/Dienste auffinden Meist mit Lease (Time-out) Mechanismus Problem beim Auffinden unbekannter Dienste Beispiele: Jini, SSDP (UPnP), Bluetooth Linklayer
Discovery Services (2/2) Device-Discovery Was ist in der Nähe, was bietet es? Aufzählung aller Geräte und Attribute Service-Discovery Gibt es einen bestimmten Dienst? Liste aller passenden Geräte Beispiel: Drucker + Laser + Farbe Scope-Problem: Welcher Bereich ist aktuell? Location Sensing (Problem Privatsphäre) Erreichbarkeit der Geräte per Multicast
Beispiel: Service discovery in Jini Client 1. finance lookup service Printing service admin admin Lookup service 4. Use printing Network service Client 2. Here I am:... admin, finance Corporate infoservice Printing service 3. Request printing Lookup service finance
Discovery Services - Implementierung Server-based Bekannter Einstiegspunkt Kosten für Server-Infrastruktur Server muss Aktualität der Services durch Leases managen Server-less Push-Modell Regelmässiges Ankündigen verfügbarer Services Verschwendung von Bandbreite und Energie Serverless Pull-Modell Multicasting der Anfragen (Gruppe=Einstiegspunkt) Client muss aus Antworten auswählen Anfragen vieler Clients sind oft redundant
Fallstudien Universal Plug and Play (UPnP) Microsoft / UPnP Forum Multicast Dmain Name Server (MDNS) Zeroconf Working Group / Apple Bonjour Service Location Protocol Sun
Universal Plug and Play Basiert auf HTTP Protokolle HTTP Multicast over IP Simple Service Discovery Protocol (SSDP) General Event Notification Architecture (GENA) Client sucht Dienst per SSDP-Anfrage Multicast-Gruppe SSDP-Antwort des Dienstanbieters URL eines XML-Dokuments mit Dienstspezifikation Advertisement: Dienstankündigung per SSDP Kommunikation Client-Dienst per SOAP vorgeschrieben Simple Object Access Protokoll (SOAP): RPC per XML UPnP-AV A.k.a DLNA (Digital Living Network Alliance) For streaming media
Basiert auf IP Multicast Domain Name Server Erweiterung des DNS-Protokolls DNS-SRV Records speichern Typ des Diensts, Adresse, Port DNS over Multicast Kein DNS-Server zwingend nötig Anfrage/Dienstantwort und Advertising per DNS DNS-Server und MDNS können koexistieren MDNS spezifiziert kein Client-Dienst-Protokoll
Service Location Protocol Basiert nicht auf existierenden Standards Anfrage und Dienstantwort per Multicast Dienstanwort liefert URL eines Service Kein Advertising Sinnvoll nur für statische Netze Directory Agents Optionale zentrale Server ersetzen Multicast Auffinden über Konfig-Datei, DHCP oder normales Service Discovery Kein Client-Dienst-Protokoll spezifiziert
Physische Nähe Beispiel: WLAN-Zugriff im Hotel soll nicht von außen verwendet werden können Feststellen des Orts Manuelle Eingabe eines Code Einstecken eines Kabels / Dongle Zwei Knöpfe gleichzeitig drücken (RF-Maus) Nahfunk durch RFID nach Annähern GPS: funktioniert nur im Freien, Privatsphäre? Andere Orts-Sensoren: nicht flächendeckend vorhanden Barcode lesen per Camera Schwacher Infrarot-Sender Leiser Audiostream
Naming for mobile Geräte Mobile Geräte sind nicht dauerhaft an selber Stelle in Netzwerk-Topologie IP-Addresse benennt fixe topologische Stelle DNS löst Name in fixe Addresse auf Systemdesign nutzt dies für Caching, Replication Namensauflösung für Mobilgeräte Ansatz 1: Eintrag am globalen Namensserver ändern Ansatz 2: Symbolischen Link einfügen
Broadcasting Einfache Lösungen Z.B. Adress Resolution Protocol (ARP) Verbraucht viel Brandbreite Empfänger muss alle Updates verarbeiten Multicasting An eine bestimmte Multicast-Gruppe Gruppe fungiert als generisches Location Service Erlaubt auffinden des nächstliegenden Dienstes Pointer-Forwarding [ ]
Pointer-Forwarding Mobiles Objekt hinterlässt Referenz bei Umzug Z.B. bei RMI Umziehendes Servant-Objekt hinterlässt Proxy Bisheriges Skeleton ruft neues Proxy auf Lange Ketten von Referenzen Antwort direkt oder über inversen Pfad? Aufrufer kann sich Shortcut merken Probleme mit Broken Links Weiterleitung über Home Location [ ]
Home Location Bekannter Ursprung eines mobilen Objekts Home verfolgt aktiv die aktuelle Location Home ist zuverlässig verfügbar Beispiel: Mobile IP Home-Agent an bekannter Home-Location Mobiler Host sendet temporäre Care-of-Address an Home-Agent Pakete werden durch Tunnel an Foreign-Agent gesandt Sender wird informiert, kann direkt an Foreign-Agent senden