Zum Hauptinhalt springen

1. Einführung

1.1. Hintergrund​

Das Constrained Application Protocol (CoAP) [RFC7252] soll RESTful-Dienste [REST] bereitstellen, die HTTP [RFC7230] nicht unähnlich sind, während die Komplexität der Implementierung sowie die Größe der ausgetauschten Pakete reduziert werden, um diese Dienste in einem stark eingeschränkten Netzwerk von selbst stark eingeschränkten Knoten [RFC7228] nützlich zu machen.

Das Modell von REST ist das eines Clients, der Repräsentationen von Ressourcen mit einem Server austauscht, wobei eine Repräsentation den aktuellen oder beabsichtigten Zustand einer Ressource erfasst. Der Server ist die Autorität für Repräsentationen der Ressourcen in seinem Namensraum. Ein Client, der am Zustand einer Ressource interessiert ist, initiiert eine Anfrage an den Server; der Server gibt dann eine Antwort mit einer Repräsentation der Ressource zurück, die zum Zeitpunkt der Anfrage aktuell ist.

Dieses Modell funktioniert nicht gut, wenn ein Client daran interessiert ist, über einen bestimmten Zeitraum eine aktuelle Repräsentation einer Ressource zu haben. Bestehende Ansätze von HTTP, wie wiederholtes Polling oder HTTP Long Polling [RFC6202], erzeugen erhebliche Komplexität und/oder Overhead und sind daher in einer eingeschränkten Umgebung weniger anwendbar.

Das in diesem Dokument spezifizierte Protokoll erweitert das CoAP-Kernprotokoll um einen Mechanismus, mit dem ein CoAP-Client eine Ressource auf einem CoAP-Server "beobachten" kann: Der Client ruft eine Repräsentation der Ressource ab und fordert an, dass diese Repräsentation vom Server aktualisiert wird, solange der Client an der Ressource interessiert ist.

Das Protokoll behält die architektonischen Eigenschaften von REST bei. Es ermöglicht hohe Skalierbarkeit und Effizienz durch die Unterstützung von Caches und Proxys. Es besteht jedoch nicht die Absicht, den vollständigen Satz von Problemen zu lösen, die die bestehenden HTTP-Lösungen lösen, oder Publish/Subscribe-Netzwerke zu ersetzen, die ein viel allgemeineres Problem lösen [RFC5989].

1.2. Protokollübersicht​

Das Protokoll basiert auf dem bekannten Beobachter-Entwurfsmuster [GOF]. In diesem Entwurfsmuster registrieren sich Komponenten, die "Beobachter" genannt werden, bei einem bestimmten, bekannten Anbieter, der "Subjekt" genannt wird, um benachrichtigt zu werden, wann immer das Subjekt eine Zustandsänderung erfährt. Das Subjekt ist für die Verwaltung seiner Liste registrierter Beobachter verantwortlich. Wenn mehrere Subjekte für einen Beobachter von Interesse sind, muss sich der Beobachter für alle separat registrieren.

                       Beobachter           Subjekt
                          |                    |
                          |    Registrierung   |
                          +------------------->|
                          |                    |
                          |   Benachrichtigung |
                          |<-------------------+
                          |                    |
                          |   Benachrichtigung |
                          |<-------------------+
                          |                    |
                          |   Benachrichtigung |
                          |<-------------------+
                          |                    |

                   Abbildung 1: Das Beobachter-Entwurfsmuster

Das Beobachter-Entwurfsmuster wird in CoAP wie folgt realisiert:

Subjekt: Im Kontext von CoAP ist das Subjekt eine Ressource im Namensraum eines CoAP-Servers. Der Zustand der Ressource kann sich im Laufe der Zeit ändern, von seltenen Aktualisierungen bis hin zu kontinuierlichen Zustandsänderungen.

Beobachter: Ein Beobachter ist ein CoAP-Client, der daran interessiert ist, zu jedem beliebigen Zeitpunkt eine aktuelle Repräsentation der Ressource zu haben.

Registrierung: Ein Client registriert sein Interesse an einer Ressource, indem er eine erweiterte GET-Anfrage an den Server initiiert. Zusätzlich zur Rückgabe einer Repräsentation der Zielressource veranlasst diese Anfrage den Server, den Client zur Liste der Beobachter der Ressource hinzuzufügen.

Benachrichtigung: Wann immer sich der Zustand einer Ressource ändert, benachrichtigt der Server jeden Client in der Liste der Beobachter der Ressource. Jede Benachrichtigung ist eine zusätzliche CoAP-Antwort, die vom Server als Antwort auf die einzelne erweiterte GET-Anfrage gesendet wird und eine vollständige, aktualisierte Repräsentation des neuen Ressourcenzustands enthält.

Abbildung 2 unten zeigt ein Beispiel für einen CoAP-Client, der sein Interesse an einer Ressource registriert und drei Benachrichtigungen erhält: die erste mit dem aktuellen Zustand bei der Registrierung und dann zwei bei Änderungen des Ressourcenzustands. Sowohl die Registrierungsanfrage als auch die Benachrichtigungen werden durch das Vorhandensein der in diesem Dokument definierten Observe-Option als solche identifiziert. In Benachrichtigungen stellt die Observe-Option zusätzlich eine Sequenznummer zur Erkennung von Umordnungen bereit. Alle Benachrichtigungen tragen das vom Client angegebene Token, sodass der Client sie leicht mit der Anfrage korrelieren kann.

                       Client                Server
                          |                    |
                          |  GET /temperature  |
                          |    Token: 0x4a     |   Registrierung
                          |  Observe: 0        |
                          +------------------->|
                          |                    |
                          |    2.05 Content    |
                          |    Token: 0x4a     |   Benachrichtigung
                          |  Observe: 12       |   über den aktuellen
                          |  Payload: 22.9 Cel |   Zustand
                          |<-------------------+
                          |                    |
                          |    2.05 Content    |
                          |    Token: 0x4a     |   Benachrichtigung
                          |  Observe: 44       |   bei einer
                          |  Payload: 22.8 Cel |   Zustandsänderung
                          |<-------------------+
                          |                    |
                          |    2.05 Content    |
                          |    Token: 0x4a     |   Benachrichtigung
                          |  Observe: 60       |   bei einer
                          |  Payload: 23.1 Cel |   Zustandsänderung
                          |<-------------------+
                          |                    |

                  Abbildung 2: Beobachten einer Ressource in CoAP

Hinweis: In diesem Dokument steht "Cel" für "Grad Celsius".

Ein Client bleibt auf der Liste der Beobachter, solange der Server das fortgesetzte Interesse des Clients an der Ressource feststellen kann. Der Server kann eine Benachrichtigung in einer bestätigbaren CoAP-Nachricht senden, um eine Bestätigung vom Client anzufordern. Wenn der Client sich abmeldet, eine Benachrichtigung ablehnt oder die Übertragung einer Benachrichtigung nach mehreren Übertragungsversuchen eine Zeitüberschreitung aufweist, wird der Client als nicht mehr an der Ressource interessiert betrachtet und vom Server aus der Liste der Beobachter entfernt.

1.3. Konsistenzmodell​

Während ein Client in der Liste der Beobachter einer Ressource steht, ist das Ziel des Protokolls, den vom Client beobachteten Ressourcenzustand so eng wie möglich mit dem tatsächlichen Zustand auf dem Server synchron zu halten.

Es lässt sich nicht vermeiden, dass Client und Server zeitweise nicht synchron sind: Erstens gibt es immer eine gewisse Latenz zwischen der Änderung des Ressourcenzustands und dem Empfang der Benachrichtigung. Zweitens können CoAP-Nachrichten mit Benachrichtigungen verloren gehen, was dazu führt, dass der Client einen alten Zustand annimmt, bis er eine neue Benachrichtigung erhält. Und drittens kann der Server irrtümlich zu dem Schluss kommen, dass der Client nicht mehr an der Ressource interessiert ist, was dazu führt, dass der Server aufhört, Benachrichtigungen zu senden, und der Client einen alten Zustand annimmt, bis er schließlich sein Interesse erneut registriert.

Das Protokoll geht dieses Problem wie folgt an:

  • Es verfolgt einen Best-Effort-Ansatz für das Senden der aktuellen Repräsentation an den Client nach einer Zustandsänderung: Clients sollten den neuen Zustand nach einer Zustandsänderung so schnell wie möglich sehen, und sie sollten so viele Zustände wie möglich sehen. Dies wird jedoch durch die Überlastungskontrolle begrenzt, sodass sich ein Client nicht darauf verlassen kann, jeden einzelnen Zustand zu beobachten, den eine Ressource durchlaufen könnte.

  • Es kennzeichnet Benachrichtigungen mit einer maximalen Dauer, bis zu der es akzeptabel ist, dass der beobachtete Zustand und der tatsächliche Zustand nicht synchron sind. Wenn das Alter der empfangenen Benachrichtigung diese Grenze erreicht, kann der Client die beigefügte Repräsentation nicht verwenden, bis er eine neue Benachrichtigung erhält.

  • Es ist nach dem Prinzip der eventuellen Konsistenz konzipiert: Das Protokoll garantiert, dass, wenn die Ressource keine neue Zustandsänderung erfährt, schließlich alle registrierten Beobachter eine aktuelle Repräsentation des neuesten Ressourcenzustands haben werden.

1.4. Beobachtbare Ressourcen​

Ein CoAP-Server ist die Autorität für die Bestimmung, unter welchen Bedingungen Ressourcen ihren Zustand ändern und somit wann Beobachter über neue Ressourcenzustände benachrichtigt werden. Das Protokoll bietet keine expliziten Mittel zum Einrichten von Auslösern oder Schwellenwerten; es liegt am Server, beobachtbare Ressourcen bereitzustellen, die ihren Zustand auf eine Weise ändern, die im Anwendungskontext nützlich ist.

Zum Beispiel könnte ein CoAP-Server mit einem angeschlossenen Temperatursensor eine oder mehrere der folgenden Ressourcen bereitstellen:

  • <coap://server/temperature>, die ihren Zustand alle paar Sekunden auf einen aktuellen Messwert des Temperatursensors ändert;

  • <coap://server/temperature/felt>, die ihren Zustand auf "COLD" ändert, wann immer der Temperaturmesswert unter einen bestimmten vorkonfigurierten Schwellenwert fällt, und auf "WARM", wann immer der Messwert einen zweiten, etwas höheren Schwellenwert überschreitet;

  • <coap://server/temperature/critical?above=42>, die ihren Zustand basierend auf dem vom Client angegebenen Parameterwert ändert, entweder alle paar Sekunden auf den aktuellen Temperaturmesswert, wenn die Temperatur den Schwellenwert überschreitet, oder auf "OK", wenn der Messwert darunter fällt;

  • <coap://server/?query=select+avg(temperature)+from+Sensor.window:time(30sec)>, die Ausdrücke beliebiger Komplexität akzeptiert und ihren Zustand entsprechend ändert.

Durch das Entwerfen von CoAP-Ressourcen, die ihren Zustand unter bestimmten Bedingungen ändern, ist es somit möglich, den Client nur dann zu aktualisieren, wenn diese Bedingungen eintreten, anstatt ihn kontinuierlich mit rohen Sensordaten zu versorgen. Durch die Parametrisierung von Ressourcen ist dies nicht auf vom Server definierte Bedingungen beschränkt, sondern kann auf beliebig komplexe, vom Client angegebene Abfragen erweitert werden. Der Anwendungsentwickler kann daher genau das richtige Maß an Komplexität für die geplante Anwendung und die beteiligten Geräte wählen und ist nicht auf einen "Einheitsmechanismus" beschränkt, der in das Protokoll integriert ist.

1.5. Anforderungsnotation​

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in RFC 2119 [RFC2119] beschrieben.

Letztes Update am