Zusammenfassung

  • RFC 7641 hält eine CoAP-Ressourcendarstellung mit Best-Effort-Benachrichtigungen aktuell; Zwischenzustände dürfen fehlen.
  • 24-Bit-Serienvergleich, die 128-Sekunden-Bedingung und Max-Age regeln Reihenfolge und Verwendbarkeit, nicht dauerhafte Speicherung oder lückenlose Wiedergabe.
  • Eine belastbare Konformitätsaussage braucht Paketvektoren über mindestens zwei Client- und Serverimplementierungen sowie sichtbare Nachweise für Frische, Lücken, Neuregistrierung und Abbruch.

Der Erfolg steht in der Antwort

Ein Client registriert sich mit GET, Observe gleich null und einem Token. Enthält die erfolgreiche 2.xx-Antwort ebenfalls Observe, hält der Server einen Beobachtereintrag für Endpunkt und Token. Weitere Benachrichtigungen sind zusätzliche Antworten auf diese eine Anfrage. Kann oder will der Server keinen Eintrag halten, darf er normal ohne Observe antworten. Der Client weiß dann, dass er abfragen muss.

Das vermeidet wiederholte Abfragen unveränderter Ressourcen. Für knappe Funkstrecken, Batteriegeräte und kleine Server ist das ein wesentlicher Effizienzgewinn. Caches und Proxies bleiben nutzbar. Die RFC grenzt Observe jedoch von allgemeinen Publish/Subscribe-Netzen ab.

Die Zustellung erfolgt nach bestem Bemühen und zielt auf eventual consistency. Wenn die Ressource nicht weiter wechselt, sollen Beobachter schließlich die aktuelle Darstellung besitzen. Bei Überlastung oder zu schnellen Änderungen darf der Server beliebig viele Zwischenzustände überspringen. Das Protokoll hält Gegenwart kompakt; es führt kein Ereignisbuch.

Serienarithmetik statt Integervergleich

Jede erfolgreiche Benachrichtigung wiederholt den Token und trägt einen Observe-Wert. Der Server verwendet die unteren 24 Bit einer streng wachsenden Folge. Der Client bestimmt mit Serienarithmetik, welche Nachricht später gesendet wurde. Nur so bleibt die Reihenfolge über den Überlauf zu null erhalten.

Nach mehr als 128 Sekunden seit der bisher frischesten Ankunft darf eine neue Benachrichtigung ohne den Serienvergleich als neuer gelten. Diese Zeitbedingung begrenzt Mehrdeutigkeit nach langer Funkstille. Sie ist kein Zeitstempel des physikalischen Ereignisses und keine Zahl ausgelassener Zustände.

Der Server darf außerdem nicht in weniger als 256 Sekunden mehr als die Hälfte des 24-Bit-Raums durchlaufen. Das macht Vergleiche möglich. Ob nach Neustart, Tokenverlust oder Proxy-Ausfall sauber weitergearbeitet wird, bleibt eine prüfbare Implementierungseigenschaft.

Max-Age beendet eine Annahme

Max-Age legt fest, wie lange eine Abweichung zwischen beobachtetem und wirklichem Zustand akzeptabel ist. Ist die Darstellung älter, darf der Client nicht mehr annehmen, sie sei aktuell. Er kann aktualisieren oder sich mit demselben Token neu registrieren.

Ablauf beweist weder Änderung noch Paketverlust noch Defekt. Die Darstellung wird unbekannt. Ob ein Produkt den letzten Wert hält, sicher stoppt, degradiert weiterläuft oder eine Person fragt, ist eine autorisierungspflichtige Anwendungsentscheidung.

Auch eine bestätigte Nachricht erzeugt keine Historie. Observe-Benachrichtigungen können confirmable oder non-confirmable sein. Ein ACK bestätigt die Ankunft dieser CoAP-Nachricht, nicht die Zustellung aller vorherigen Ressourcenzustände.

Abbruch braucht Fehlertests

Ein Client kann die Beobachtung vergessen und eine spätere unbekannte confirmable Benachrichtigung mit Reset ablehnen. Er kann auch GET mit gleichem Token und Observe gleich eins senden. Geht Reset oder Deregistrierung verloren, behält der Server den Eintrag vorerst. Bestätigungen, Wiederholungen und Timeouts sammeln ihn später ein.

Darum gehören verlorener Reset und verlorene Deregistrierung in eine Konformitätsmatrix. Ein lokales UI, das „beendet“ zeigt, ist kein Nachweis, dass der entfernte Zustand gelöscht wurde.

Der Proxy erzeugt eine neue Beweisschicht

Ein Intermediär kann mehrere nachgelagerte Beobachter zu einer vorgelagerten Registrierung zusammenfassen. Jeder Hop setzt eigene Observe-Werte, Nachrichtentypen und Max-Age auf Basis seiner lokalen Darstellung. Das ist standardkonform und skalierbar. Es bedeutet zugleich, dass der Client die aktuelle Sicht des Proxys erhält.

Ein guter Test vergleicht direkte und vermittelte Pfade, Neustarts und Cache-Validierung. Er zeigt, ob ein Zustand aufgrund der RFC-Frischeregel verworfen, vom Server nie benachrichtigt oder im Proxy verdichtet wurde.