8. Multicast CoAP (Multicast-CoAP)
CoAP unterstützt das Senden von Anfragen an eine IP-Multicast-Gruppe. Dies wird durch eine Reihe von Deltas zu Unicast-CoAP definiert. Eine allgemeinere Diskussion der CoAP-Gruppenkommunikation wird in [GROUPCOMM] bereitgestellt.
Ein CoAP-Endpunkt, der einen Dienst bereitstellt, der von anderen Endpunkten mittels Multicast-Dienstentdeckung entdeckt werden kann, tritt einer oder mehreren der entsprechenden All-CoAP-Nodes-Multicast-Adressen (Abschnitt 12.8) bei und lauscht auf dem Standard-CoAP-Port. Beachten Sie, dass ein Endpunkt Multicast-Anfragen auf anderen Multicast-Adressen (einschließlich der All-Nodes-IPv6-Adresse) oder über Broadcast auf IPv4 empfangen kann; daher MUSS ein Endpunkt darauf vorbereitet sein, solche Nachrichten zu empfangen, KANN sie jedoch ignorieren, wenn Multicast-Dienstentdeckung nicht gewünscht wird.
8.1. Messaging Layer (Nachrichtenschicht)
Eine Multicast-Anfrage ist dadurch gekennzeichnet, dass sie in einer CoAP-Nachricht übertragen wird, die an eine IP-Multicast-Adresse anstelle eines CoAP-Endpunkts adressiert ist. Solche Multicast-Anfragen MÜSSEN Non-confirmable sein.
Ein Server SOLLTE sich bewusst sein, dass eine Anfrage über Multicast angekommen ist, z.B. durch die Verwendung moderner APIs wie IPV6_RECVPKTINFO [RFC3542], falls verfügbar.
Um eine Implosion von Fehlerantworten zu vermeiden, DARF ein Server, wenn er sich bewusst ist, dass eine Anfrage über Multicast angekommen ist, KEINE Reset-Nachricht als Antwort auf eine Non-confirmable-Nachricht zurückgeben. Wenn er es nicht weiß, KANN er wie üblich eine Reset-Nachricht als Antwort auf eine Non-confirmable-Nachricht zurückgeben. Da eine solche Reset-Nachricht für den Absender identisch mit einer für eine Unicast-Nachricht gesendeten aussieht, MUSS der Absender die Verwendung von Nachrichten-IDs vermeiden, die auch noch von diesem Endpunkt mit einem Endpunkt aktiv sind, das die Multicast-Nachricht empfangen könnte.
Zum Zeitpunkt der Erstellung können Multicast-Nachrichten nur in UDP und nicht in DTLS übertragen werden. Dies bedeutet, dass die in diesem Dokument für CoAP definierten Sicherheitsmodi nicht auf Multicast anwendbar sind.
8.2. Request/Response Layer (Anfrage/Antwort-Schicht)
Wenn ein Server sich bewusst ist, dass eine Anfrage über Multicast angekommen ist, KANN der Server die Anfrage immer ignorieren, insbesondere wenn er keine nützliche Antwort hat (z.B. wenn er nur eine leere Nutzlast oder eine Fehlerantwort hätte). Diese Entscheidung kann von der Anwendung abhängen. (Zum Beispiel antwortet der Server bei der in [RFC6690] beschriebenen Abfragefilterung nicht auf eine Multicast-Anfrage, wenn der Filter nicht übereinstimmt. Weitere Beispiele finden sich in [GROUPCOMM].)
Wenn ein Server sich entscheidet, auf eine Multicast-Anfrage zu antworten, SOLLTE er nicht sofort antworten. Stattdessen SOLLTE er eine Dauer für den Zeitraum wählen, in dem er antworten möchte. Für die Zwecke dieser Darstellung nennen wir die Länge dieses Zeitraums Leisure. Der spezifische Wert dieses Leisure kann von der Anwendung abhängen oder KANN wie unten beschrieben abgeleitet werden. Der Server SOLLTE dann einen zufälligen Zeitpunkt innerhalb des gewählten Leisure-Zeitraums wählen, um die Unicast-Antwort auf die Multicast-Anfrage zurückzusenden. Wenn weitere Antworten basierend auf derselben Multicast-Adress-Mitgliedschaft gesendet werden müssen, beginnt ein neuer Leisure-Zeitraum frühestens nach Beendigung des vorherigen.
Um einen Wert für Leisure zu berechnen, SOLLTE der Server eine Gruppengröße-Schätzung G, eine Ziel-Datenübertragungsrate R (beide konservativ gewählt) und eine geschätzte Antwortgröße S haben; eine grobe Untergrenze für Leisure kann dann wie folgt berechnet werden
lb_Leisure = S * G / R
Zum Beispiel kann für eine Multicast-Anfrage mit Link-Local-Bereich auf einem 2.4 GHz IEEE 802.15.4 (6LoWPAN) Netzwerk G (relativ konservativ) auf 100 gesetzt werden, S auf 100 Bytes und die Zielrate auf 8 kbit/s = 1 kB/s. Die resultierende Untergrenze für Leisure beträgt 10 s.
Wenn ein CoAP-Endpunkt keine geeigneten Daten hat, um einen Wert für Leisure zu berechnen, KANN er auf DEFAULT_LEISURE zurückgreifen.
Beim Abgleichen einer Antwort mit einer Multicast-Anfrage MUSS nur das Token übereinstimmen; der Quell-Endpunkt der Antwort muss nicht (und wird nicht) derselbe sein wie der Ziel-Endpunkt der ursprünglichen Anfrage.
Zum Zwecke der Interpretation der Location-*-Optionen und aller in der Darstellung eingebetteten Links wird der Anfrage-URI (d.h. der Basis-URI, relativ zu dem die Antwort interpretiert wird) gebildet, indem die Multicast-Adresse in der Host-Komponente des ursprünglichen Anfrage-URI durch die literale IP-Adresse des tatsächlich antwortenden Endpunkts ersetzt wird.
8.2.1. Caching (Caching)
Wenn ein Client eine Multicast-Anfrage stellt, stellt er immer eine neue Anfrage an die Multicast-Gruppe (da es neue Gruppenmitglieder geben kann, die in der Zwischenzeit beigetreten sind oder die vorherige Anfrage nicht erhalten haben). Er KANN einen Cache mit den empfangenen Antworten aktualisieren. Er verwendet dann sowohl zwischengespeicherte-noch-frische als auch neue Antworten als Ergebnis der Anfrage.
Eine Antwort, die als Antwort auf eine GET-Anfrage an eine Multicast-Gruppe empfangen wurde, KANN verwendet werden, um eine nachfolgende Anfrage auf dem zugehörigen Unicast-Anfrage-URI zu erfüllen. Der Unicast-Anfrage-URI wird erhalten, indem der Autoritätsteil des Anfrage-URI durch die Transportschicht-Quelladresse der Antwortnachricht ersetzt wird.
Ein Cache KANN eine Antwort revalidieren, indem er eine GET-Anfrage auf dem zugehörigen Unicast-Anfrage-URI stellt.
Eine GET-Anfrage an eine Multicast-Gruppe DARF KEINE ETag-Option enthalten. Der Mechanismus zur Unterdrückung von Antworten, die der Client bereits hat, wird für weitere Studien überlassen.
8.2.2. Proxying (Proxying)
Wenn ein Forward-Proxy eine Anfrage mit einem Proxy-Uri oder einem aus Proxy-Scheme konstruierten URI empfängt, der eine Multicast-Adresse angibt, erhält der Proxy eine Reihe von Antworten wie oben beschrieben und sendet alle Antworten (sowohl zwischengespeicherte-noch-frische als auch neue) an den ursprünglichen Client zurück.
Diese Spezifikation bietet keine Möglichkeit, den Unicast-modifizierten Anfrage-URI (Basis-URI) in den so weitergeleiteten Antworten anzugeben. Proxying von Multicast-Anfragen wird in [GROUPCOMM] ausführlicher diskutiert; eine Möglichkeit, das Basis-URI-Problem anzugehen, findet sich in Abschnitt 3 von [CoAP-MISC].