8. Multicast CoAP (CoAP Multicast)
CoAP prend en charge l'émission de requêtes vers un groupe multicast IP. Ceci est défini par une série de deltas au CoAP unicast. Une discussion plus générale sur la communication de groupe CoAP est fournie dans [GROUPCOMM].
Un point de terminaison CoAP qui fournit un service découvrable par d'autres points de terminaison utilisant la découverte de service multicast rejoint une ou plusieurs des adresses multicast all-CoAP-nodes appropriées (Section 12.8) et écoute sur le port CoAP par défaut. Notez qu'un point de terminaison peut recevoir des requêtes multicast sur d'autres adresses multicast (y compris l'adresse IPv6 all-nodes) ou via diffusion sur IPv4; par conséquent, un point de terminaison DOIT être préparé à recevoir de tels messages mais PEUT les ignorer si la découverte de service multicast n'est pas souhaitée.
8.1. Messaging Layer (Couche de Messagerie)
Une requête multicast est caractérisée par le fait d'être transportée dans un message CoAP qui est adressé à une adresse multicast IP au lieu d'un point de terminaison CoAP. De telles requêtes multicast DOIVENT être Non-confirmables.
Un serveur DEVRAIT être conscient qu'une requête est arrivée via multicast, par exemple en utilisant des API modernes telles que IPV6_RECVPKTINFO [RFC3542], si disponibles.
Pour éviter une implosion de réponses d'erreur, lorsqu'un serveur est conscient qu'une requête est arrivée via multicast, il NE DOIT PAS retourner un message Reset en réponse à un message Non-confirmable. S'il ne le sait pas, il PEUT retourner un message Reset en réponse à un message Non-confirmable comme d'habitude. Parce qu'un tel message Reset semblera identique à celui envoyé pour un message unicast à l'expéditeur, l'expéditeur DOIT éviter d'utiliser des ID de message qui sont également encore actifs depuis ce point de terminaison avec tout point de terminaison qui pourrait recevoir le message multicast.
Au moment de la rédaction, les messages multicast ne peuvent être transportés que dans UDP et non DTLS. Cela signifie que les modes de sécurité définis dans ce document pour CoAP ne s'appliquent pas au multicast.
8.2. Request/Response Layer (Couche Requête/Réponse)
Lorsqu'un serveur est conscient qu'une requête est arrivée via multicast, le serveur PEUT toujours ignorer la requête, en particulier s'il n'a pas de réponse utile (par exemple, s'il n'aurait qu'une charge utile vide ou une réponse d'erreur). Cette décision peut dépendre de l'application. (Par exemple, dans le filtrage de requête décrit dans [RFC6690], le serveur ne répond pas à une requête multicast si le filtre ne correspond pas. D'autres exemples se trouvent dans [GROUPCOMM].)
Si un serveur décide de répondre à une requête multicast, il NE DEVRAIT PAS répondre immédiatement. Au lieu de cela, il DEVRAIT choisir une durée pour la période de temps pendant laquelle il a l'intention de répondre. Aux fins de cette exposition, nous appelons la longueur de cette période le Leisure. La valeur spécifique de ce Leisure peut dépendre de l'application ou PEUT être dérivée comme décrit ci-dessous. Le serveur DEVRAIT alors choisir un point temporel aléatoire dans la période de leisure choisie pour renvoyer la réponse unicast à la requête multicast. Si d'autres réponses doivent être envoyées en fonction de la même appartenance à l'adresse multicast, une nouvelle période de leisure commence au plus tôt après la fin de la précédente.
Pour calculer une valeur pour Leisure, le serveur DEVRAIT avoir une estimation de la taille du groupe G, un taux de transfert de données cible R (tous deux choisis de manière conservatrice), et une taille de réponse estimée S; une borne inférieure approximative pour Leisure peut alors être calculée comme
lb_Leisure = S * G / R
Par exemple, pour une requête multicast avec une portée locale de lien sur un réseau 2.4 GHz IEEE 802.15.4 (6LoWPAN), G peut être (relativement conservativement) fixé à 100, S fixé à 100 octets, et le taux cible à 8 kbit/s = 1 kB/s. La borne inférieure résultante pour le Leisure est de 10 s.
Si un point de terminaison CoAP n'a pas de données appropriées pour calculer une valeur pour Leisure, il PEUT recourir à DEFAULT_LEISURE.
Lors de la correspondance d'une réponse à une requête multicast, seul le token DOIT correspondre; le point de terminaison source de la réponse n'est pas (et ne sera pas) le même que le point de terminaison de destination de la requête originale.
Aux fins de l'interprétation des options Location-* et de tous les liens intégrés dans la représentation, l'URI de requête (c'est-à-dire l'URI de base par rapport auquel la réponse est interprétée) est formé en remplaçant l'adresse multicast dans le composant Host de l'URI de requête originale par l'adresse IP littérale du point de terminaison répondant réellement.
8.2.1. Caching (Mise en Cache)
Lorsqu'un client effectue une requête multicast, il effectue toujours une nouvelle requête au groupe multicast (puisqu'il peut y avoir de nouveaux membres du groupe qui ont rejoint entre-temps ou qui n'ont pas reçu la requête précédente). Il PEUT mettre à jour un cache avec les réponses reçues. Il utilise ensuite à la fois les réponses mises en cache-encore fraîches et nouvelles comme résultat de la requête.
Une réponse reçue en réponse à une requête GET à un groupe multicast PEUT être utilisée pour satisfaire une requête ultérieure sur l'URI de requête unicast associé. L'URI de requête unicast est obtenu en remplaçant la partie autorité de l'URI de requête par l'adresse source de la couche de transport du message de réponse.
Un cache PEUT revalider une réponse en effectuant une requête GET sur l'URI de requête unicast associé.
Une requête GET à un groupe multicast NE DOIT PAS contenir d'option ETag. Le mécanisme pour supprimer les réponses que le client possède déjà est laissé à l'étude future.
8.2.2. Proxying (Mise en Proxy)
Lorsqu'un proxy direct reçoit une requête avec un Proxy-Uri ou un URI construit à partir de Proxy-Scheme qui indique une adresse multicast, le proxy obtient un ensemble de réponses comme décrit ci-dessus et renvoie toutes les réponses (à la fois mises en cache-encore fraîches et nouvelles) au client original.
Cette spécification ne fournit aucun moyen d'indiquer l'URI de requête modifié en unicast (URI de base) dans les réponses ainsi transférées. La mise en proxy de requêtes multicast est discutée plus en détail dans [GROUPCOMM]; une façon d'aborder le problème de l'URI de base peut être trouvée dans la Section 3 de [CoAP-MISC].