Summary

  • Le projet CoRE pubsub, révision 22, mis à jour le 2 novembre 2026, propose un courtier CoAP pour des clients susceptibles de rester déconnectés longtemps. Un éditeur publie par PUT; un abonné observe la ressource ou lit sa dernière représentation. Le texte est encore en évaluation à l'IESG.
  • La section 3.3 définit la récupération de la dernière donnée du sujet. L'accès aux représentations antérieures et la quantité d'historique conservée sont renvoyés à un travail futur.
  • Un sujet existant, une publication acceptée et un abonnement établi correspondent à trois constats différents. Sans option Observe dans la réponse, l'abonnement n'a pas abouti, même si le code de réponse indique un succès.

Prenons un capteur de température et un poste de maintenance momentanément hors ligne. Le capteur signale une montée dangereuse, puis une température normale avant le retour du poste. Au réveil, celui-ci reçoit la mesure normale la plus récente. Il connaît la dernière mesure reçue par le courtier. Il ne possède pas, grâce à cette seule réponse, le relevé des changements survenus pendant son absence. L'exemple est construit pour éprouver le contrat du protocole; le projet ne présente pas une panne industrielle précise.

Dans le projet de l'IETF, le courtier héberge des collections de sujets. Chaque sujet dispose d'une ressource de configuration et d'une ressource distincte pour les données. L'éditeur envoie une requête PUT à la seconde. L'abonné y adresse un GET avec Observe: 0, selon le mécanisme du RFC 7641. Le courtier fait circuler des représentations d'état entre clients qui ne sont pas nécessairement connectés simultanément. L'adresse de la ressource de données n'a même pas à reprendre la forme de celle du sujet administratif: il faut lire la propriété topic-data.

La dernière valeur répond à une question limitée

Le texte distingue plusieurs absences. À la création d'un sujet, sa ressource de données existe mais aucune représentation n'y a encore été publiée: le projet prévoit 2.06 No Content. Un GET sur une ressource inexistante donne normalement 4.04 Not Found. Si une valeur a été publiée, le GET fournit la dernière représentation. Ces trois situations ne devraient pas devenir le même voyant vide sur un écran de supervision.

Le projet dit expressément qu'il définit seulement la récupération de la dernière représentation. Il évoque une éventuelle spécification future pour lire les anciennes et fixer combien le courtier en garde. L'exploitant qui veut savoir si une alarme a surgi pendant une coupure doit donc posséder un journal d'événements distinct, avec ses propres règles de conservation. Le courtier peut se souvenir de la dernière valeur publiée sans être l'historien de la période perdue.

L'inscription à une observation fournit une autre occasion de se tromper. Une réponse 2.05 Content accompagnée d'Observe confirme l'abonnement et apporte la donnée courante. Pour un sujet encore vide, la réponse peut être 2.06 No Content avec Observe; la première publication arrivera ensuite en notification. Sans option Observe, le client doit considérer l'abonnement comme raté. Le courtier peut omettre cette option lorsqu'il a atteint la limite max-subscribers. Lire seulement le code 2.05 ou 2.06 ferait passer une réponse utile pour un abonnement durable qui n'existe pas.

Le sujet possède aussi sa propre durée de vie. Sa suppression efface la ressource de configuration et la ressource de données et clôt les observations par un dernier 4.04. Une date d'expiration peut déclencher cette suppression. Pour expliquer une interruption, l'exploitant doit regarder le cycle de vie du sujet, la capacité du courtier et le résultat exact de l'inscription, pas uniquement la dernière valeur affichée.

Le reçu du courtier ne vaut pas réception chez l'abonné

Un PUT réussi reçoit en général 2.04 Changed dans le modèle de requête et réponse du RFC 7252. Cela établit l'acceptation par le courtier, pas la remise à chaque abonné ni l'action de l'application. En cas de publications trop rapides, le courtier peut répondre 4.29 Too Many Requests et fixer dans Max-Age le délai avant une nouvelle tentative. Un registre d'incident sérieux conserve les refus aussi bien que les publications acceptées.

Le projet demande une communication sécurisée entre chaque client et le courtier. Il recommande aussi de protéger le contenu de bout en bout, avec authentification de sa source, pour que l'abonné puisse vérifier son origine. Une liaison chiffrée avec le courtier ne donne pas, à elle seule, cette preuve sur le capteur. Même une mesure authentique ne certifie pas que le poste de maintenance a reçu l'alarme ou déclenché une intervention.

Le gain du courtier est réel: un appareil qui dort peut retrouver un état récent sans forcer tous les participants à rester éveillés ensemble. L'angle mort est tout aussi précis. Le projet ne fournit ni historique complet ni mesure de déploiement montrant ce qui survit à une coupure. Le fait qui changerait une décision d'exploitation est un journal ordonné des publications acceptées et des livraisons aux abonnés pendant la période manquante. Sans lui, une mesure revenue à la normale ne peut pas acquitter l'heure où elle ne l'était pas.

Projet CoRE pubsub · RFC 7641 · RFC 7252