Summary

  • Le projet CoAP Observe multicast, version 17, daté du 2 novembre 2026, propose une notification commune aux clients qui suivent la même ressource. Il reste un Internet-Draft actif.
  • L'option Feedback-Divider sollicite au hasard une partie des clients intéressés. Chacun répond avec une probabilité de 1 / 2^Q ; le serveur reçoit R confirmations et calcule l'indicateur E = R × 2^Q.
  • Dans l'exemple du texte, le compteur attend 32 observateurs, 18 sont actifs, cinq décident de répondre et une réponse se perd. Quatre réponses arrivées donnent l'indicateur 16 et, avec l'amortisseur choisi pour l'exemple, un nouveau compte estimé de 16.

Un serveur publie la nouvelle valeur d'une ressource que surveillent des dizaines de petits appareils. RFC 7641 permet à chaque client CoAP de s'inscrire pour recevoir les changements. Si le serveur écrit à chacun, son travail augmente avec le nombre d'inscrits. Le projet de multicast lui permet d'envoyer une notification unique au groupe. L'économie est immédiate. L'information sur les destinataires l'est beaucoup moins.

Le serveur crée localement une requête d'observation « fantôme » pour représenter le groupe et partage un Token entre ses membres. Aucun appareil fictif ne circule sur le réseau. Les clients reçoivent les paramètres et écoutent l'adresse de diffusion. Pour le serveur, émettre une notification est un événement unique. Savoir combien de machines restent intéressées en est un autre. Son compteur d'observateurs est présenté comme une estimation approximative, utile notamment pour décider si le groupe mérite d'être maintenu.

Un sondage remplace la feuille de présence

La section 8 de la version 17 propose une vérification sans déclencher une avalanche de réponses. Le serveur joint Feedback-Divider à une notification, avec une valeur Q. Tout client compatible qui souhaite rester abonné tire un entier entre zéro et 2^Q, borne supérieure exclue. Seul celui qui tire zéro envoie une nouvelle inscription unicast, après un délai aléatoire. Les autres se taisent, même s'ils sont toujours là.

Le serveur compte les confirmations reçues, R, puis calcule E = R × 2^Q. Avec une chance sur quatre de répondre, quatre confirmations suggèrent seize clients. Elles ne prouvent pas que seize clients ont vu la notification. Le tirage lui-même varie et des réponses peuvent être perdues. Le projet reconnaît explicitement que les pertes de paquets faussent l'estimation. La diffusion économise les envois ; le serveur récupère une approximation de la taille du public.

Le compteur doit aussi intégrer les arrivées pendant le sondage. Le projet prend sa valeur courante COUNT', la compare à l'estimation antérieure N, et applique la correction (E − N) / D avec un amortisseur entier positif D. La mise à jour doit être atomique par rapport aux nouvelles inscriptions : corriger le passé ne doit pas effacer un client arrivé entre-temps. Cette discipline protège l'état du serveur, sans produire un accusé de réception pour chaque appareil.

Le calcul fourni par les auteurs est parlant. Le serveur estime 32 observateurs et choisit Q=2, soit une chance sur quatre pour chacun de répondre. Dix-huit sont effectivement actifs. Cinq sont tirés, mais un message se perd. Le serveur en reçoit quatre et extrapole seize. Avec D=1, son compteur passe de 32 à 16 ; le groupe reste actif. Le chiffre réel de 18 appartient à l'exemple rédigé pour expliquer le mécanisme. Un serveur en exploitation ne le connaîtrait pas par magie.

Une meilleure facture réseau, une autre décision à prendre

Mettre Q=0 invite tous les clients actifs à confirmer, au prix d'un trafic retour plus élevé ; les pertes restent possibles. Demander moins souvent réduit encore ce trafic mais laisse vieillir le compteur. Un amortisseur plus fort ralentit les corrections. La politique applicative détermine à quel rythme relancer le sondage et quand mettre fin à l'observation groupée. Si elle coupe trop tôt, des clients encore intéressés attendront une voie de notification qui n'existe plus. Si elle garde un groupe vide, le gain de ressources se réduit.

RFC 7252 définit le fonctionnement de CoAP sur lequel repose cette proposition. Le projet change le coût de distribution d'une mise à jour Observe. Son compteur mesure un intérêt estimé, pas la réception de chaque message. Pour une interface de températures, cette approximation peut suffire à choisir un mode d'envoi. Pour une consigne dont dépend une action précise, il faut une preuve attachée à chaque appareil concerné.

Le dossier officiel ne donne aucune mesure sur une installation réelle ni sur sa distribution de pertes. Un essai contrôlé, avec le nombre réel d'appareils, les réponses tirées, les réponses perdues et les notifications effectivement reçues, permettrait de fixer l'erreur du compteur. Le marché proposé est simple : une notification pour tous, et la connaissance du public rendue par tirage au sort.

Projet CoAP multicast Observe · Fiche Datatracker · RFC 7641 · RFC 7252