Eddystone URL, SSDP und mDNS unterstützen das physische Web

Eddystone URL, SSDP und mDNS unterstützen das physische Web

Einführung in das physische Web

Leuchtfeuer eignen sich für alle Arten von Anwendungsszenarien, die eine Kommunikation zwischen Alltagsgegenständen und ihrer Umgebung erfordern. Das physische Web hilft Benutzern, die daraus resultierenden Möglichkeiten optimal zu nutzen. In diesem Artikel, Wir werden vorstellen, wie physisches Web funktioniert, und es besteht kein Zweifel, dass die Eddystone-URL eine wichtige Rolle bei der Arbeit mit dem Eddystone spielt.

Im 2014, Google präsentierte sein Open-Source-Projekt Physical Web mit dem Ziel, die virtuelle Welt noch enger mit der realen zu verbinden. Bushaltestellen, Sehenswürdigkeiten, Alltagsgegenstände oder Supermarktartikel – allgemein gesagt, Alle können nun unabhängig voneinander Nachrichten über Beacons an Smartphones senden. Die Basis für eine solche Kommunikation ist das Bluetooth Low Energy (WURDEN) Funktechnologie. Wenn ein Gegenstand mit einem Leuchtfeuer ausgestattet wurde, Es kann Nachrichten an Smartphones senden, die BLE unterstützen, zum Beispiel über Verzögerungen informieren, Sonderangebote oder Kampagnentage.

In diesem Kontext, Das physische Web sorgt dafür, unter anderem, dass Benutzer nicht überall neue Apps installieren müssen, kann aber die Nachrichten auf einer einheitlichen Oberfläche anzeigen. Es kann in fast allen Fällen verwendet werden, in denen Benutzer an Informationen über ihre Umgebung interessiert sind oder in denen eine Interaktion zwischen ihnen und intelligenten Objekten erforderlich ist. Um sich ein besseres Bild von solchen Szenarien zu machen, Es folgen drei kurze Anwendungsbeispiele.

Die intelligente Bushaltestelle: Eine Bushaltestelle in der Nähe könnte über ihr Smartphone erkennen, wann der nächste Bus kommt. In diesem Fall, Der physische Web-BLE-Sensor sendet eine URL, die zur Website der Bushaltestelle führt. Um sie von anderen zu unterscheiden, Die URL würde einen Identifikationscode des Stopps enthalten.

Interaktion mit Automaten: Ein Verkaufsautomat mit Internetverbindung sendet eine URL, über die Kunden über die Zahlungsfunktion des Verkaufsautomaten auf eine Website zugreifen können, wenn sie kein Bargeld bei sich haben. Die URL enthält ein Token, das sich nach jedem Kauf dynamisch ändert. Der Computer und die auf dem Smartphone geöffnete Website stellen mit demselben Token eine Verbindung zum Back-End-Server des Anbieters her. Nach dem Kauf wird bearbeitet, Der Server sendet eine Anfrage an den Verkaufsautomaten, um die gekauften Produkte auszugeben. Das physische Web wird verwendet, um die URL auf das Smartphone zu übertragen. Alle anderen Schritte finden wie gewohnt im Internet statt. Beispielsweise, Die sogenannten Web-Sockets können für die bidirektionale Kommunikation zwischen Maschine oder Website und Server verwendet werden.

Überwachte Haushaltsgeräte: Das physische Netz kann auch zur Steuerung und Überwachung von Haushaltsgeräten wie der Waschmaschine verwendet werden. Jedes Gerät sendet eine URL, die auf eine IP-Adresse verweist und nur erreichbar ist, wenn eine Verbindung zum lokalen Netzwerk besteht. Die Sichtbarkeit der URL kann auf Geräte im Netzwerk beschränkt sein, wenn Netzwerkerkennungstechniken wie mDNS und SSDP anstelle von BLE verwendet werden.

Physisches Web oder einzelne Apps

Im Gegensatz zu anderen Informationsangeboten (z.B. Fahrplaninformation oder Tourismusverband), Hier müssen Benutzer für jeden Anbieter eine eigene App installieren, Das physische Web integriert die von den Beacons übertragene Eddystone-URL, als wären sie eine Suchabfrage auf einer Seite. So können Benutzer mit nur einer App intelligente Objekte in ihrer Umgebung finden und direkt mit ihnen interagieren. Ein weiterer Vorteil: Es werden keine proaktiven Benachrichtigungen gesendet. Der Benutzer sieht nur dann eine Liste von Objekten in seinem Bereich, wenn er möchte.

Neben der BLE, MOKOSmart, in dem der Autor arbeitet, schlägt eine Methode zum Senden und Empfangen von URLs in lokalen Netzwerken vor, die auf dem Simple Service Discovery Protocol basieren (SSDP). Mit Hilfe von SSDP, Es ist möglich, die Sichtbarkeit der gesendeten Eddystone-URL in lokalen Netzwerken einzuschränken und so die Verbindungssicherheit zu erhöhen.

Das physische Web ist als Projekt unter der Apache-Lizenz auf MOKOSmart verfügbar und enthält Implementierungen für Plattformen wie Android, iOS, und Node.js.. Die physischen Webanwendungen für Android und iOS sind im Apple App Store und im Google Play Store verfügbar. Alle Anwendungen sind als Prototypen zu verstehen, Damit können Entwickler frühzeitig mit dem physischen Web experimentieren. In der Zukunft, Es sollte neben Smartphones auch auf anderen Mobilgeräten verfügbar sein.

eddystone url

Wie funktioniert das physische Web??

Das physische Web soll eine Erweiterung des Internets sein. Wie alle Webtechnologien, es steht allen offen und jeder kann es weiterentwickeln. Da das System auf der Anzeige von URLs basiert, Es ist dezentralisiert und wird von niemandem kontrolliert. Die Eddystone-URL kann zu einfachen Informationsseiten führen, zu komplexer, interaktive Web-Apps oder sogar native Anwendungen. Das physische Web ist vergleichbar mit der Suche im Web:

Der Benutzer ruft eine Liste von Objekten aus seiner Umgebung auf.
Eine Liste der URLs wird angezeigt.
Der Benutzer wählt eine aus.
Die URL wird im Browserfenster angezeigt.
Folgende Aspekte müssen aus technischer Sicht berücksichtigt werden:
1. Feedback abschicken
2. Geschichte
3. Gerettet
4. Gemeinschaft

• Senden und Empfangen von URLs: Es gibt viele Möglichkeiten, URLs zu senden. Das physische Web unterstützt derzeit die Übertragung über BLE, mDNS, und SSDP (Mehr dazu im nächsten Abschnitt).
Grundlegende Informationen von Websites abrufen: Der physische Webclient sammelt gefundene URLs und sendet sie zusammen mit allen relevanten Informationen (z.B. Signalstärke) zu einem Webdienst. Dies, im Gegenzug, ruft die grundlegenden Informationen wie den Titel auf, Beschreibung, und Symbol der Website und gibt die Suchergebnisse an den Kunden zurück. Die Prototyp-Implementierung des Webdienstes ist im GitHub-Repository des Projekts verfügbar.

• Anzeigen der Ergebnisse: Ein Ranking ist wichtig, wenn es darum geht, die vielen URL-sendenden Geräte aus der Region anzuzeigen. Der physische Webclient kann nach Signalstärke sortieren, persönliche Präferenz und andere Kriterien. Das System sollte Spam im Voraus aussortieren. Da haben Suchmaschinen das gleiche Problem, Ihr Ansatz kann für das physische Web verwendet werden. In der Ergebnisanzeige, Der Benutzer klickt auf ein Listenobjekt und der Browser öffnet die zugehörige Website.

• Wie erwähnt, Das physische Web kennt derzeit drei Möglichkeiten zum Senden und Empfangen von URLs. Sie basieren auf zwei verschiedenen Prozessen: Bluetooth Low Energy und Network Service Discovery. Theoretisch, Weitere Methoden könnten in Zukunft hinzugefügt werden. Beispielsweise, Entwickler könnten Audio-Wasserzeichentechnologie verwenden, um eine URL in ein Audiosignal einzubetten. In diesem Fall, Der physische Webclient müsste erweitert werden, um Audiosignale empfangen und die darin enthaltenen URLs dekodieren zu können.

Ble Bluetooth und Eddystone

Der erste Entwurf des physischen Web verwendet BLE, um die URL an das entsprechende Paket zu senden. Die Technologie ist sehr energieeffizient, insbesondere wenn das Produkt, das es verwendet, im Sendemodus betrieben wird (nicht anschließbarer BLE-Modus), wie im Fall des physischen Web. Kleine BLE-Geräte können fast zwei Jahre lang eine Eddystone-URL mit einer einzigen Knopfzelle senden.

Einer der Grundbausteine ​​des Physical Web ist die Eddystone-URL. Als Protokollspezifikation, Eddystone definiert ein Bluetooth-Nachrichtenformat mit geringem Stromverbrauch für Proximity Beacons basierend auf der Bluetooth-Kernspezifikation. Es werden verschiedene Rahmentypen beschrieben, die Beacons einzeln oder in Kombination verwenden können: Eddystone-UID, Eddystone-TLM, und die oben genannte Eddystone-URL, Dies ist die einzige, die für das physische Web relevant ist.

Eine Eddystone-Nachricht besteht aus zwei grundlegenden Datentypen in einem Werbedatenblock (ANZEIGE): UUID und Datendienst. Beide Typen verwenden eine universell eindeutige 16-Bit-Kennung (UUID) das entspricht den Bluetooth-Standards. Der für Eddystone reservierte UUID-Dienst ist 0xFEAA. Es bietet einen Mechanismus für effiziente, Plattformübergreifendes Scannen im Hintergrund, das sowohl für Android als auch für iOS zulässig ist. Die nachfolgenden Bytes des AD-Blocks enthalten die für den Frame spezifischen Daten. Das erste Byte definiert den Rahmentyp. Derzeit werden nur die vier höchstwertigen Bits verwendet. Die vier unteren sind für die spätere Verwendung reserviert und müssen den Wert haben 0000.

Der Eddystone-UID-Frame sendet eine eindeutige 16-Byte-Beacon-ID, die aus einer 10-Byte-Namespace-ID und einer 6-Byte-Instanz-ID besteht. Obwohl die Namespace-ID verwendet werden kann, um einen bestimmten Satz von Beacons zu gruppieren, Die Instanz-ID ist nützlich, um die Geräte in der Gruppe zu identifizieren.

Wenn Sie sich das Konzept der Eddystone-UID ansehen, Es funktioniert ähnlich wie die von Apple in eingeführten iBeacons 2013. Das iBeacon-Paket enthält 16 Bytes in der Nähe der UUID, eine 2-Byte-Primärdomäne, und eine 2-Byte-Sekundärdomäne. iBeacon-Pakete enthalten eine 16-Byte-Proximity-UUID, 2-Byte-Major- und 2-Byte-Minor-Felder. Die Proximity-UUID kann verwendet werden, um eine Organisation oder Anwendung wie ein Unternehmen zu identifizieren. Haupt- und Nebenfelder ermöglichen eine detailliertere Zuordnung der von der UUID festgelegten Identität, wie im Fall einer Niederlassung. Eddystone-TLM sendet jetzt telemetrische Informationen wie den Batteriestatus, Gerätetemperatur und Anzahl der vom Beacon gesendeten Pakete.

Der Eddystone-URL-Frame sendet eine reduzierte Version der durch Codierung generierten URL. Die Komprimierung ermöglicht es, mit dem begrenzten Werbepaket mehr Daten zu transportieren. Das Format des ersten 11 Bytes (Bytes 0 durch 10) der Eddystone-Nachricht ist für alle Rahmentypen gleich. Wie die folgenden Bytes gesetzt werden (ab Byte 11), jedoch, hängt vom Rahmentyp ab:

• Byte 11 definiert den Rahmentyp. Der Wert für Eddystone-URL-Frames beträgt 0x10.
• Byte 12 definiert die Leistung von TX. Dies ist ein vorzeichenbehafteter 8-Bit-Ganzzahlwert, wie in der Bluetooth-Kennlinie für die Sendeleistung beschrieben

Netzwerkdiensterkennung

Zusätzlich zu BLE-Beacons und Eddystone-URL, Netzwerkerkennungsmethoden wie SSDP und mDNS bieten die Möglichkeit, URLs zu übertragen. Sie können auch URLs an Geräte in lokalen Netzwerken senden. Die Methode hat zwei Vorteile gegenüber BLE: Zuerst, Nur Benutzer, die in lokalen Netzwerken angemeldet sind, können die URLs sehen, und zweitens, Es gibt keine URL-Längenbeschränkung wie bei BLE.

Die Verwendung von Network Discovery für das physische Web ist in Situationen sinnvoll, in denen Sicherheit und Datenschutz eine Schlüsselrolle spielen. Ein Beispiel wäre der Smart-Home-Bereich, wenn der Zugriff auf Geräte nur auf Personen aus demselben Haushalt beschränkt werden sollte.

Das Simple Service Discovery-Protokoll (SSDP) ist ein Netzwerkprotokoll für die Werbung und Erkennung von Diensten und Geräten in lokalen Netzwerken. Es bildet die Erkennungsschicht des universellen Plug-and-Play-Protokolls (UPnP) und hilft bei der Veröffentlichung neu hinzugefügter Geräte, die als Kontrollpunkte definiert sind. Außerdem können Sie nach Geräten und bestimmten Diensten suchen.

Solche Funktionen basieren auf den beiden Arten von SSDP-Nachrichten. Zuerst, Es gibt die Ankündigungsnachricht, die ein Gerät sendet, sobald es dem Netzwerk hinzugefügt wird. Die Nachricht an die Standard-Multicast-Adresse und den Port 239.255.255.250:1900 ist ssdp: am Leben. Kontrollpunkte warten auf den Port, um SSDP-Nachrichten zu empfangen und so neue Geräte und Dienste erkennen zu können. Bevor UPnP-Geräte aus dem Netzwerk verschwinden oder nicht mehr verfügbar sind, Sie müssen die Nachricht ssdp senden: Auf Wiedersehen an dieselbe Multicast-Adresse und den entsprechenden Port.

Andererseits, Es gibt eine Erkennungsfunktion, mit der SSDP es den Kontrollpunkten ermöglicht, Geräte und Dienste von Interesse auch im Netzwerk zu finden. In diesem Fall, Ein Kontrollpunkt sendet eine Suchanforderung an die Multicast-Adresse und den Port 239.255.255.250:1900. UPnP-Geräte, die die angeforderten Dienste unterstützen, senden eine Unicast-Antwort an die Adresse des Prüfpunkts, der die Anforderung gesendet hat. Das Format der Antwort ähnelt der SSDP-Nachricht vom Typ ssdp: am Leben.

Physical Web unterstützt SSDP zum Senden und Empfangen von URLs in lokalen Netzwerken. Das Fraunhofer FOKUS entwickelte das Konzept und die Implementierung des entsprechenden Mechanismus. Die Implementierung umfasst die Integration von SSDP in die physische Web-App für Android und iOS zum Empfangen von URLs über das Protokoll. Zusätzlich, Ein plattformübergreifendes Tool, das auf Node.js basiert, ist verfügbar, um URLs auf die gleiche Weise zu senden.

Bei Verwendung von SSDP, Ein physisches Webgerät, das mit dem lokalen Netzwerk verbunden ist, sendet die folgende SSDP: lebendige Nachricht, sobald sie im Netzwerk verfügbar ist:

BENACHRICHTIGEN * HTTP / 1.1 GASTGEBER: 239.255.255.250:1900
CACHE-CONTROL: maximales Alter = Sekunden bis zum Ablauf der Werbung
ORT: URL der zu bewerbenden Webseite
NT: Urne: physische-web-org: Gerät: Basic: 1
NTS: ssdp: am Leben
SERVER: DAS / Version UPnP / 1.0 Produkt / Ausführung
USN: Werbung UUID
Die NOTIFY-Methode in der ersten Zeile zeigt an, dass es sich um eine Werbebotschaft handelt. Während der LOCATION-Header die physische Web-URL definiert, die gesendet wird, Der NT-Header definiert den Gerätetyp, was im Fall des physischen Netzes Urne ist: physische-web-org: Gerät: Basic: 1. Die ssdp: Der lebendige Wert des NTS-Headers zeigt an, dass das physische Webgerät verfügbar ist. Schließlich, Der USN-Header enthält einen eindeutigen Namen, mit dem das Gerät identifiziert werden kann. Physische Webclients, die auf Smartphones oder Tablets ausgeführt werden, hören die Multicast-Adresse und den Port ab 239.255.255.250:1900 und filtern Sie die physischen Web-SSDP-Nachrichten, indem Sie den Wert des NT-Headers überprüfen. Anschließend können Sie die SSDP-Nachricht analysieren und den Wert des LOCATION-Headers lesen, der die gesendete URL enthält.

Physische Webgeräte müssen das folgende ssdp senden: Tschüss-Nachricht vor dem Verschwinden aus dem Netzwerk:

BENACHRICHTIGEN * HTTP / 1.1 GASTGEBER: 239.255.255.250: 1900
NT: Urne: physische-web-org: Gerät: Basic: 1
NTS: ssdp: Tschüss
USN: Werbung UUID
ssdp: bye-bye macht deutlich, dass das physische Webgerät ab sofort nicht mehr verfügbar ist. Der Wert des USN-Headers bleibt der gleiche wie im ssdp: lebendige Nachricht. Physische Webclients, die eine solche Nachricht erhalten, suchen nach der mit der USN verknüpften URL und entfernen sie dann aus der Liste.