Summary

  • Der CoAP-Multicast-Observe-Entwurf, Revision 17, vom 2. November 2026 sieht eine gemeinsame Benachrichtigung für Clients vor, die dieselbe Ressource beobachten. Er ist ein aktiver Internet-Draft.
  • Feedback-Divider fordert Antworten von einer Zufallsauswahl interessierter Clients. Jeder antwortet mit Wahrscheinlichkeit 1 / 2^Q; der Server empfängt R Bestätigungen und berechnet E = R × 2^Q.
  • Das Beispiel des Entwurfs beginnt mit geschätzten 32 Beobachtern. Tatsächlich sind 18 aktiv; fünf entscheiden sich zu antworten, eine Antwort geht verloren. Vier Ankünfte ergeben den Indikator 16 und unter den Beispielbedingungen einen neuen Schätzwert von 16.

Viele kleine Geräte beobachten einen gemeinsamen Zustand. Nach RFC 7641 können CoAP-Clients sich für Änderungen registrieren. Eine gesonderte Antwort an jedes Gerät lässt die Arbeit des Servers mit der Zahl der Beobachter wachsen. Der neue Entwurf fasst sie zu einer Gruppenbeobachtung zusammen und verschickt eine einzige Multicast-Benachrichtigung. Der Server spart Sendearbeit. Zugleich verliert er den unmittelbaren Blick darauf, wie viele Geräte wirklich noch zuhören.

Für die Gruppe erzeugt der Server lokal eine „Phantom“-Observe-Anfrage und ordnet ihr einen gemeinsamen Token zu. Kein Phantomgerät versendet diese Anfrage. Die Clients erhalten die Gruppenparameter und lauschen auf Nachrichten. Der Server kann den Versand einer Nachricht protokollieren; damit hat er weder die Zahl der noch interessierten Empfänger noch die erfolgreiche Zustellung an jedes Gerät erfasst. Sein Beobachterzähler ist ausdrücklich nur eine grobe Schätzung.

Eine Stichprobe ersetzt die Anwesenheitsliste

Abschnitt 8 der Revision 17 versieht die Nachricht mit Feedback-Divider und dem Wert Q. Jeder unterstützende Client, der weiter zuhören möchte, zieht zufällig eine ganze Zahl von null bis unter 2^Q. Nur bei null sendet er nach zufälliger Wartezeit eine neue unicast Observe-Registrierung. Andere bleiben stumm, auch wenn sie aktiv sind. Das Verfahren verhindert, dass alle Empfänger gleichzeitig antworten und die Einsparung durch eine Antwortwelle wieder verlieren.

Der Server zählt die gültigen angekommenen Bestätigungen als R und multipliziert mit 2^Q. So entsteht E. Bei einer Antwortwahrscheinlichkeit von einem Viertel legen vier Antworten sechzehn Teilnehmer nahe. Sie sind keine sechzehn Einzelquittungen. Die Ziehung schwankt; Antworten können auf dem Rückweg ausfallen. Der Entwurf benennt Paketverlust als Verzerrung. Der Multicast spart Sendungen und liefert dem Server dafür nur eine geschätzte Publikumsgröße zurück.

Während der Befragung können neue Clients hinzukommen. Der Entwurf nimmt den aktuellen Zähler COUNT', vergleicht E mit der alten Schätzung N und korrigiert um (E − N) / D, wobei D ein positiver ganzzahliger Dämpfer ist. Die Aktualisierung muss gegenüber neuen Registrierungen atomar sein. Eine alte Stichprobe darf einen gerade hinzugekommenen Beobachter nicht aus dem Zähler schreiben. Diese Regel hält den internen Stand konsistent, beweist aber keine Nachrichtenzustellung.

Im Zahlenbeispiel schätzt der Server 32 Teilnehmer und setzt Q=2, also eine Antwortchance von eins zu vier. Tatsächlich sind 18 aktiv. Fünf ziehen die Antwort, doch eine geht verloren. Aus vier Ankünften wird E=16; mit D=1 sinkt der Zähler von 32 auf 16, die Gruppe bleibt bestehen. Die wirklichen 18 kennen die Leser des Beispiels, weil die Autoren sie nennen. Ein Server im Betrieb hätte nur seine vier Antworten und seine statistische Annahme.

Weniger Verkehr, mehr Entscheidung beim Betreiber

Mit Q=0 kann der Server jeden aktiven Client zur Antwort auffordern. Das kostet mehr Rückverkehr, und Paketverlust bleibt möglich. Selteneres Nachfragen spart weiter, macht den Zähler aber älter. Ein größerer Dämpfer verlangsamt Veränderungen. Die Anwendung entscheidet, wann sie wieder fragt und ab welchem Wert die Gruppenbeobachtung endet. Ein zu früher Abbruch lässt interessierte Geräte ohne gemeinsamen Kanal zurück; eine leere Gruppe kostet unnötig Ressourcen. Die Schwelle ist eine Betreiberentscheidung.

RFC 7252 liefert die CoAP-Grundlage. Der Entwurf senkt die Verteilkosten von Observe-Aktualisierungen. Sein Zähler schätzt Interesse und bestätigt weder Empfang noch Verarbeitung einer einzelnen Nachricht. Für eine Temperaturanzeige mag das als Grundlage für die Wahl des Transportwegs genügen. Eine Anweisung an ein bestimmtes Gerät verlangt dessen eigene Rückmeldung.

Die offiziellen Unterlagen enthalten keine Messung einer realen Installation oder ihrer Verlustverteilung. Ein kontrollierter Versuch mit bekannter Teilnehmerzahl, gezogenen Antworten, verlorenen Paketen und tatsächlicher Zustellung würde die Fehlerbreite sichtbar machen. Das Geschäft ist klar: Eine Nachricht für alle ist billig. Die Zahl dieser „alle“ wird ausgelost.

CoAP-Multicast-Observe-Entwurf · Datatracker · RFC 7641 · RFC 7252