Aller au contenu principal

1. Introduction

1.1. Contexte​

Le protocole d'application contraint (CoAP) [RFC7252] est destiné à fournir des services RESTful [REST] assez semblables à HTTP [RFC7230] tout en réduisant la complexité de mise en œuvre ainsi que la taille des paquets échangés afin de rendre ces services utiles dans un réseau hautement contraint de nœuds eux-mêmes hautement contraints [RFC7228].

Le modèle de REST est celui d'un client échangeant des représentations de ressources avec un serveur, où une représentation capture l'état actuel ou prévu d'une ressource. Le serveur est l'autorité pour les représentations des ressources dans son espace de noms. Un client intéressé par l'état d'une ressource initie une requête au serveur ; le serveur renvoie alors une réponse avec une représentation de la ressource qui est actuelle au moment de la requête.

Ce modèle ne fonctionne pas bien lorsqu'un client est intéressé à avoir une représentation actuelle d'une ressource sur une période de temps. Les approches existantes de HTTP, telles que l'interrogation répétée ou l'interrogation longue HTTP [RFC6202], génèrent une complexité et/ou une surcharge importantes et sont donc moins applicables dans un environnement contraint.

Le protocole spécifié dans ce document étend le protocole de base CoAP avec un mécanisme permettant à un client CoAP "d'observer" une ressource sur un serveur CoAP : le client récupère une représentation de la ressource et demande que cette représentation soit mise à jour par le serveur tant que le client est intéressé par la ressource.

Le protocole conserve les propriétés architecturales de REST. Il permet une grande évolutivité et efficacité grâce à la prise en charge des caches et des proxys. Il n'est cependant pas prévu de résoudre l'ensemble complet des problèmes que les solutions HTTP existantes résolvent ou de remplacer les réseaux de publication/abonnement qui résolvent un problème beaucoup plus général [RFC5989].

1.2. Aperçu du protocole​

Le protocole est basé sur le modèle de conception d'observateur bien connu [GOF]. Dans ce modèle de conception, des composants appelés "observateurs" s'enregistrent auprès d'un fournisseur spécifique et connu appelé le "sujet" pour être notifiés chaque fois que le sujet subit un changement d'état. Le sujet est responsable de l'administration de sa liste d'observateurs enregistrés. Si plusieurs sujets intéressent un observateur, l'observateur doit s'enregistrer séparément pour chacun d'eux.

                       Observateur           Sujet
                          |                    |
                          |   Enregistrement   |
                          +------------------->|
                          |                    |
                          |    Notification    |
                          |<-------------------+
                          |                    |
                          |    Notification    |
                          |<-------------------+
                          |                    |
                          |    Notification    |
                          |<-------------------+
                          |                    |

                   Figure 1 : Le modèle de conception d'observateur

Le modèle de conception d'observateur est réalisé dans CoAP comme suit :

Sujet : Dans le contexte de CoAP, le sujet est une ressource dans l'espace de noms d'un serveur CoAP. L'état de la ressource peut changer au fil du temps, allant de mises à jour peu fréquentes à des transformations d'état continues.

Observateur : Un observateur est un client CoAP qui est intéressé à avoir une représentation actuelle de la ressource à tout moment donné.

Enregistrement : Un client enregistre son intérêt pour une ressource en initiant une requête GET étendue au serveur. En plus de renvoyer une représentation de la ressource cible, cette requête amène le serveur à ajouter le client à la liste des observateurs de la ressource.

Notification : Chaque fois que l'état d'une ressource change, le serveur notifie chaque client de la liste des observateurs de la ressource. Chaque notification est une réponse CoAP supplémentaire envoyée par le serveur en réponse à la requête GET étendue unique et comprend une représentation complète et mise à jour du nouvel état de la ressource.

La figure 2 ci-dessous montre un exemple d'un client CoAP enregistrant son intérêt pour une ressource et recevant trois notifications : la première avec l'état actuel lors de l'enregistrement, puis deux lors de changements de l'état de la ressource. La requête d'enregistrement et les notifications sont toutes deux identifiées comme telles par la présence de l'option Observe définie dans ce document. Dans les notifications, l'option Observe fournit en outre un numéro de séquence pour la détection de réorganisation. Toutes les notifications portent le jeton spécifié par le client, de sorte que le client peut facilement les corréler à la requête.

                       Client                Serveur
                          |                    |
                          |  GET /temperature  |
                          |    Token: 0x4a     |   Enregistrement
                          |  Observe: 0        |
                          +------------------->|
                          |                    |
                          |    2.05 Content    |
                          |    Token: 0x4a     |   Notification de
                          |  Observe: 12       |   l'état actuel
                          |  Payload: 22.9 Cel |
                          |<-------------------+
                          |                    |
                          |    2.05 Content    |
                          |    Token: 0x4a     |   Notification lors
                          |  Observe: 44       |   d'un changement
                          |  Payload: 22.8 Cel |   d'état
                          |<-------------------+
                          |                    |
                          |    2.05 Content    |
                          |    Token: 0x4a     |   Notification lors
                          |  Observe: 60       |   d'un changement
                          |  Payload: 23.1 Cel |   d'état
                          |<-------------------+
                          |                    |

                  Figure 2 : Observation d'une ressource dans CoAP

Note : Dans ce document, "Cel" signifie "degrés Celsius".

Un client reste sur la liste des observateurs tant que le serveur peut déterminer l'intérêt continu du client pour la ressource. Le serveur peut envoyer une notification dans un message CoAP confirmable pour demander un accusé de réception au client. Lorsque le client se désenregistre, rejette une notification, ou que la transmission d'une notification expire après plusieurs tentatives de transmission, le client est considéré comme n'étant plus intéressé par la ressource et est retiré par le serveur de la liste des observateurs.

1.3. Modèle de cohérence​

Tant qu'un client est dans la liste des observateurs d'une ressource, l'objectif du protocole est de maintenir l'état de la ressource observé par le client aussi étroitement synchronisé que possible avec l'état réel sur le serveur.

Il est inévitable que le client et le serveur soient parfois désynchronisés : Premièrement, il y a toujours une certaine latence entre le changement de l'état de la ressource et la réception de la notification. Deuxièmement, les messages CoAP avec des notifications peuvent être perdus, ce qui amènera le client à supposer un ancien état jusqu'à ce qu'il reçoive une nouvelle notification. Et troisièmement, le serveur peut conclure à tort que le client n'est plus intéressé par la ressource, ce qui amènera le serveur à cesser d'envoyer des notifications et le client à supposer un ancien état jusqu'à ce qu'il enregistre finalement à nouveau son intérêt.

Le protocole traite ce problème comme suit :

  • Il suit une approche du mieux possible pour envoyer la représentation actuelle au client après un changement d'état : les clients devraient voir le nouvel état après un changement d'état dès que possible, et ils devraient voir autant d'états que possible. Cela est toutefois limité par le contrôle de congestion, de sorte qu'un client ne peut pas compter sur l'observation de chaque état unique qu'une ressource pourrait traverser.

  • Il étiquette les notifications avec une durée maximale jusqu'à laquelle il est acceptable que l'état observé et l'état réel soient désynchronisés. Lorsque l'âge de la notification reçue atteint cette limite, le client ne peut pas utiliser la représentation incluse jusqu'à ce qu'il reçoive une nouvelle notification.

  • Il est conçu sur le principe de la cohérence éventuelle : le protocole garantit que si la ressource ne subit pas de nouveau changement d'état, tous les observateurs enregistrés auront finalement une représentation actuelle du dernier état de la ressource.

1.4. Ressources observables​

Un serveur CoAP est l'autorité pour déterminer dans quelles conditions les ressources changent leur état et donc quand les observateurs sont notifiés des nouveaux états de ressources. Le protocole n'offre pas de moyens explicites pour configurer des déclencheurs ou des seuils ; il appartient au serveur d'exposer des ressources observables qui changent leur état d'une manière utile dans le contexte de l'application.

Par exemple, un serveur CoAP avec un capteur de température attaché pourrait exposer une ou plusieurs des ressources suivantes :

  • <coap://server/temperature>, qui change son état toutes les quelques secondes pour une lecture actuelle du capteur de température ;

  • <coap://server/temperature/felt>, qui change son état à "COLD" chaque fois que la lecture de température tombe en dessous d'un certain seuil préconfiguré et à "WARM" chaque fois que la lecture dépasse un second seuil légèrement plus élevé ;

  • <coap://server/temperature/critical?above=42>, qui change son état en fonction de la valeur du paramètre spécifié par le client, soit toutes les quelques secondes à la lecture de température actuelle si la température dépasse le seuil, soit à "OK" lorsque la lecture tombe en dessous ;

  • <coap://server/?query=select+avg(temperature)+from+Sensor.window:time(30sec)>, qui accepte des expressions d'une complexité arbitraire et change son état en conséquence.

Ainsi, en concevant des ressources CoAP qui changent leur état sous certaines conditions, il est possible de mettre à jour le client uniquement lorsque ces conditions se produisent au lieu de lui fournir continuellement des données de capteur brutes. En paramétrant les ressources, cela ne se limite pas aux conditions définies par le serveur, mais peut être étendu à des requêtes arbitrairement complexes spécifiées par le client. Le concepteur d'application peut donc choisir exactement le bon niveau de complexité pour l'application envisagée et les appareils impliqués et n'est pas contraint à un mécanisme "taille unique" intégré dans le protocole.

1.5. Notation des exigences​

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans la RFC 2119 [RFC2119].

Dernière mise à jour le