Seite 4: Network Service Discovery

Inhaltsverzeichnis

Neben BLE-Beacons bieten Network-Discovery-Methoden wie SSDP und mDNS die Möglichkeit, URLs zu übertragen. Sie können darüber hinaus URLs an Geräte in lokalen Netzwerken aussenden. Die Methode hat zwei Vorteile gegenüber BLE: Erstens können nur in lokale Netzwerke eingeloggte Nutzer die URLs sehen und zweitens gibt es keine URL-Längenbeschränkung wie bei BLE.

Der Einsatz von Network Discovery für das Physical Web ist in Situationen sinnvoll, in denen Sicherheit und Privatsphäre eine zentrale Rolle spielen. Ein Beispiel wäre der Bereich Smart Home, wenn der Zugang zu Geräten nur auf Menschen aus demselben Haushalt begrenzt sein soll.

Das Simple Service Discovery Protocol (SSDP) ist ein Netzwerkprotokoll zur Bewerbung und Entdeckung von Diensten und Geräten in lokalen Netzwerken. Es bildet den Discovery-Layer des Universal-Plug-&-Play-Protokolls (UPnP) und hilft dabei, neu hinzugefügte Geräte bekannt zu machen, die als Kontrollpunkte definiert werden. Es ermöglicht außerdem, nach Geräten und bestimmten Diensten zu suchen.

Grundlage für derartige Funktionen sind die zwei Arten von SSDP-Nachrichten. Zum einen gibt es die Advertisement-Nachricht, die ein Gerät aussendet, sobald es dem Netzwerk hinzugefügt wird. Die Nachricht an die Standard-Multicast-Adresse und den Port 239.255.255.250:1900 lautet ssdp:alive. Kontrollpunkte lauschen auf dem Port, um SSDP-Nachrichten zu empfangen und so neue Geräte und Dienste detektieren zu können. Bevor UPnP-Geräte aus dem Netzwerk verschwinden oder nicht mehr verfügbar sind, müssen sie die Nachricht ssdp:byebye an die gleiche Multicast-Adresse und den entsprechenden -Port senden.

Zum anderen gibt es eine Discovery-Funktion, bei dem SSDP den Kontrollpunkten erlaubt, selbst im Netzwerk Geräte und Dienste von Interesse zu finden. In dem Fall sendet ein Kontrollpunkt eine Suchanfrage an die Multicast-Adresse und den -Port 239.255.255.250:1900. UPnP-Geräte, welche die angefragten Dienste unterstützen, senden eine Unicast-Antwort an die Adresse des Kontrollpunkts, der die Anfrage geschickt hat. Das Format der Antwort ähnelt der SSDP-Nachricht vom Typ ssdp:alive.

Physical Web unterstützt SSDP, um URLs in lokalen Netzwerken zu senden und zu empfangen. Das Konzept und die Implementierung des entsprechenden Mechanismus entwickelte das Fraunhofer FOKUS. Die Umsetzung umfasst die Integration von SSDP in die Physical-Web-App für Android und iOS zum Empfangen von URLs über das Protokoll. Darüber hinaus steht dort ein plattformübergreifendes Tool auf Grundlage von Node.js zur Verfügung, um URLs auf dem selben Weg versenden zu können.

Ein mit dem lokalen Netzwerk verbundenes Physical-Web-Gerät sendet beim Einsatz von SSDP die folgende ssdp:alive-Nachricht, sobald es im Netzwerk verfügbar ist:

NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 
CACHE-CONTROL: max-age = seconds until advertisement expires 
LOCATION: URL of the web page to advertise 
NT: urn:physical-web-org:device:Basic:1 
NTS: ssdp:alive 
SERVER: OS/version UPnP/1.0 product/version 
USN: advertisement UUID

Die NOTIFY-Methode in der ersten Zeile gibt an, dass es sich um eine Advertise-Nachricht handelt. Während der LOCATION-Header die Physical-Web-URL festlegt, die ausgesendet wird, definiert der NT-Header den Gerätetyp, der im Fall des Physical Web urn:physical-web-org:device:Basic:1 lautet. Der Wert ssdp:alive des NTS-Headers gibt an, dass das Physical-Web-Gerät verfügbar ist. Zuletzt liefert der USN-Header einen einzigartigen Namen, der sich zur Identifikation des Geräts nutzen lässt. Physical-Web-Clients, die auf Smartphones oder Tablets laufen, lauschen der Multicast-Adresse sowie dem -Port 239.255.255.250:1900 und filtern die Physical-Web-SSDP-Nachrichten, indem sie den Wert des NT-Headers prüfen. Im Anschluss können sie die SSDP-Nachricht analysieren und den Wert des LOCATION-Headers lesen, der die gesendete URL trägt.

Physical-Web-Geräte müssen die folgende ssdp:byebye-Nachricht senden, bevor sie aus dem Netzwerk verschwinden:

NOTIFY * HTTP/1.1 HOST:239.255.255.250:1900
NT:urn:physical-web-org:device:Basic:1
NTS:ssdp:byebye 
USN: advertisement UUID

ssdp:byebye macht dabei deutlich, dass das Physical-Web-Gerät von nun an nicht mehr verfügbar ist. Der Wert des USN-Headers bleibt der gleiche wie in der ssdp:alive-Nachricht. Physical-Web-Clients, die eine derartige Meldung erhalten, suchen nach der URL, die mit der USN in Verbindung steht, und entfernen sie anschließend aus der Liste.

Die Clients sind darüber hinaus in der Lage, Physical-Web-Objekte bei Bedarf selbst zu suchen. Da eines der Kernprinzipien des Physical Webs lautet, keine proaktiven Benachrichtigungen zu versehen, ist solch ein Vorgehen besonders wünschenswert. Der Nutzer sieht nur eine Liste von Geräten, wenn er möchte. Physical-Web-Clients müssen die folgende Suchanfrage an die Standard-Multicast-Adresse und -Port 239.255.255.250:1900 schicken:

M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900
MAN: "ssdp:discover" MX: seconds to delay response
ST:urn:physical-web-org:device:Basic:1

Mit M-SEARCH in der ersten Zeile ist klargestellt, dass es sich um eine Suchanfrage handelt. Der MX-Header definiert die maximale Wartezeit in Sekunden. Im letzten Teil des ST-Headers spezifiziert urn:physical-web-org:device:Basic:1, dass nach Physical-Web-Objekten gesucht wird. Alle Geräte im Netzwerk, die auf der Multicast-Adresse und dem -Port lauschen, empfangen die Suchanfrage und nur Physical-Web-Objekte senden die folgende Unicast-Response zur Adresse des anfragenden Clients:

HTTP/1.1 200 OK 
CACHE-CONTROL: max-age = seconds until advertisement expires 
DATE: when response was generated 
LOCATION: URL of the web page to advertise 
SERVER: OS/version UPnP/1.0 product/version
ST:urn:physical-web-org:device:Basic:1 
USN: advertisement UUID

Die Antwort-Nachricht enthält in etwa die gleichen Informationen wie die ssdp:alive-Nachricht. Der Physical-Web-Client sammelt die URLs von allen empfangenen Nachrichten und bietet sie dem Nutzer an.