Après Max-Age, la bonne réponse n’est pas « faux » mais « je ne sais plus »

Résumé

• La RFC 7641 fournit un suivi au mieux de l’état courant d’une ressource CoAP ; elle avertit qu’un client ne peut pas compter sur la réception de chaque état intermédiaire.
• Max-Age, la comparaison sur 24 bits et la règle temporelle de 128 secondes déterminent ce qui peut être tenu pour actuel, sans constituer une file durable ni un journal d’événements.
• Une automatisation responsable conserve la dernière représentation acceptée et les preuves de fraîcheur, rend les lacunes visibles et choisit un autre mécanisme lorsque chaque transition doit être attestée.

Une requête GET qui dure

L’observation commence par une requête GET portant l’option Observe à zéro et un jeton choisi par le client. Si la réponse 2.xx contient elle aussi Observe, le serveur a créé une entrée liée au point d’extrémité et au jeton. Les messages suivants sont des réponses supplémentaires à cette requête initiale. Si le serveur refuse ou ne peut pas conserver cette entrée, il peut répondre comme à un GET ordinaire, sans Observe. Le client sait alors qu’il devra interroger la ressource.

L’économie est réelle. Une ressource stable n’exige plus une répétition de requêtes identiques. Un lien étroit transporte des représentations lorsqu’elles changent, et les caches ou intermédiaires peuvent agréger la demande. Mais la RFC ferme elle-même la porte à une lecture excessive : Observe n’a pas vocation à remplacer les systèmes généraux de publication et d’abonnement.

Son modèle est celui de la cohérence éventuelle. Le serveur cherche à maintenir la représentation observée aussi près que possible de son état réel. Il peut toutefois sauter un nombre quelconque d’états intermédiaires lorsque les changements sont plus rapides que le réseau ou lorsqu’il y a congestion. Une mesure reçue est donc une vue de l’état, non un reçu pour chaque transition physique.

Trois horloges qu’il ne faut pas confondre

La valeur Observe est formée des 24 bits de poids faible d’une séquence strictement croissante. Le client applique une arithmétique sérielle pour décider quel message a été envoyé le plus récemment, même autour du retour à zéro. Une comparaison naïve d’entiers renverserait l’ordre au passage de la borne.

La RFC ajoute le temps local de réception. Après plus de 128 secondes depuis la notification tenue pour la plus fraîche, une nouvelle arrivée peut être considérée comme plus récente sans s’appuyer sur la comparaison des séquences. Cette règle borne l’ambiguïté d’un petit espace numérique. Elle ne date pas l’événement métier et ne dit pas combien de changements ont eu lieu pendant le silence.

Max-Age joue encore un autre rôle. Il indique pendant combien de temps l’écart entre état observé et état réel reste acceptable. Une fois la limite dépassée, le client ne doit plus supposer que sa représentation est actuelle. Il peut rafraîchir ou se réinscrire. L’expiration n’établit ni changement, ni perte, ni panne.

Un tableau de bord devrait donc afficher « périmé » ou « état inconnu », pas fabriquer une valeur normale. Dans un système de commande, le choix entre maintien, arrêt sûr, poursuite dégradée ou validation humaine appartient au propriétaire de l’application. Observe transporte des représentations ; il ne fixe pas la politique de risque.

L’accusé de réception ne reconstitue pas le passé

Une notification peut utiliser un message confirmable ou non confirmable, indépendamment de la requête initiale. L’accusé de réception d’un message confirmable prouve son arrivée au niveau CoAP. Il ne prouve pas que toutes les représentations antérieures ont été envoyées, reçues, conservées ou appliquées.

La distinction est essentielle pour les alarmes. Si une ressource passe brièvement de normal à critique puis revient à normal pendant une congestion, un client peut finir avec la bonne valeur actuelle sans avoir vu l’intervalle critique. C’est conforme au modèle de cohérence éventuelle et potentiellement insuffisant pour l’application. Le défaut serait de vendre le premier comme s’il satisfaisait automatiquement la seconde.

Annuler demande aussi de l’état

Le client peut oublier une observation. Quand une notification confirmable inconnue arrivera, il la rejettera par Reset et le serveur finira par supprimer l’entrée. Il peut aussi envoyer explicitement un GET avec le même jeton et Observe à un. Ni Reset ni la désinscription ne sont à l’abri d’une perte. Le client peut croire la relation terminée alors que le serveur conserve encore son état.

Cette dissociation a un coût sur les petits serveurs et les radios. La RFC prévoit une collecte progressive des observateurs morts, notamment par des notifications confirmables et des délais. Une application qui exige une fin rapide doit conserver un résultat observable de désinscription et une stratégie de répétition.

L’intermédiaire possède son propre présent

Un proxy peut regrouper plusieurs abonnés aval dans une seule observation amont. Chaque saut produit ses propres valeurs Observe, choisit ses types de message et fixe Max-Age d’après sa représentation locale. Le gain d’échelle est important. La conséquence est que le client lit le présent du proxy, pas la séquence brute du serveur d’origine.

Il n’y a là aucune faute normative. La responsabilité commence lorsque l’interface cache quel saut a rafraîchi, agrégé, redémarré ou cessé d’observer. Les essais doivent donc traverser l’intermédiaire et comparer ses traces à celles de l’origine.