4. Message Transmission (Transmission de messages)

Les messages CoAP sont échangés de manière asynchrone entre les points de terminaison CoAP. Ils sont utilisés pour transporter les requêtes et réponses CoAP, dont la sémantique est définie dans la section 5.

Comme CoAP est lié à des transports non fiables tels qu'UDP, les messages CoAP peuvent arriver dans le désordre, apparaître en double ou disparaître sans préavis. Pour cette raison, CoAP implémente un mécanisme de fiabilité léger, sans essayer de recréer l'ensemble complet des fonctionnalités d'un transport comme TCP. Il possède les caractéristiques suivantes:

• Fiabilité de retransmission simple stop-and-wait avec back-off exponentiel pour les messages Confirmable.

• Détection des doublons pour les messages Confirmable et Non-confirmable.

4.1. Messages and Endpoints (Messages et points de terminaison)

Un point de terminaison CoAP est la source ou la destination d'un message CoAP. La définition spécifique d'un point de terminaison dépend du transport utilisé pour CoAP. Pour les transports définis dans cette spécification, le point de terminaison est identifié en fonction du mode de sécurité utilisé (voir section 9): Sans sécurité, le point de terminaison est uniquement identifié par une adresse IP et un numéro de port UDP. Avec d'autres modes de sécurité, le point de terminaison est identifié comme défini par le mode de sécurité.

Il existe différents types de messages. Le type d'un message est spécifié par le champ Type de l'en-tête CoAP.

Séparément du type de message, un message peut porter une requête, une réponse ou être vide (Empty). Ceci est signalé par le champ Request/Response Code dans l'en-tête CoAP et est pertinent pour le modèle requête/réponse. Les valeurs possibles pour ce champ sont maintenues dans les registres de codes CoAP (section 12.1).

Un message vide a le champ Code défini à 0.00. Le champ Token Length DOIT être défini à 0 et les octets de données NE DOIVENT PAS être présents après le champ Message ID. S'il y a des octets, ils DOIVENT être traités comme une erreur de format de message.

4.2. Messages Transmitted Reliably (Messages transmis de manière fiable)

La transmission fiable d'un message est initiée en marquant le message comme Confirmable dans l'en-tête CoAP. Un message Confirmable porte toujours soit une requête soit une réponse, sauf s'il est utilisé uniquement pour provoquer un message Reset, auquel cas il est vide. Un destinataire DOIT soit (a) accuser réception d'un message Confirmable avec un message Acknowledgement, soit (b) rejeter le message si le destinataire manque de contexte pour traiter le message correctement, y compris les situations où le message est vide, utilise un code avec une classe réservée (1, 6 ou 7), ou a une erreur de format de message. Le rejet d'un message Confirmable s'effectue en envoyant un message Reset correspondant et en l'ignorant autrement. Le message Acknowledgement DOIT faire écho au Message ID du message Confirmable et DOIT porter une réponse ou être vide (voir sections 5.2.1 et 5.2.2). Le message Reset DOIT faire écho au Message ID du message Confirmable et DOIT être vide. Le rejet d'un message Acknowledgement ou Reset (y compris le cas où l'Acknowledgement porte une requête ou un code avec une classe réservée, ou le message Reset n'est pas vide) s'effectue en l'ignorant silencieusement. Plus généralement, les destinataires de messages Acknowledgement et Reset NE DOIVENT PAS répondre avec des messages Acknowledgement ou Reset.

L'expéditeur retransmet le message Confirmable à des intervalles exponentiellement croissants, jusqu'à ce qu'il reçoive un accusé de réception (ou un message Reset) ou épuise ses tentatives.

La retransmission est contrôlée par deux éléments qu'un point de terminaison CoAP DOIT suivre pour chaque message Confirmable qu'il envoie en attendant un accusé de réception (ou reset): un timeout et un compteur de retransmission. Pour un nouveau message Confirmable, le timeout initial est défini sur une durée aléatoire (souvent pas un nombre entier de secondes) entre ACK_TIMEOUT et (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (voir section 4.8), et le compteur de retransmission est défini à 0. Lorsque le timeout est déclenché et que le compteur de retransmission est inférieur à MAX_RETRANSMIT, le message est retransmis, le compteur de retransmission est incrémenté et le timeout est doublé. Si le compteur de retransmission atteint MAX_RETRANSMIT lors d'un timeout, ou si le point de terminaison reçoit un message Reset, alors la tentative de transmission du message est annulée et le processus d'application est informé de l'échec. D'autre part, si le point de terminaison reçoit un accusé de réception à temps, la transmission est considérée comme réussie.

Cette spécification ne formule pas d'exigences strictes concernant la précision des horloges utilisées pour implémenter l'algorithme de back-off exponentiel binaire ci-dessus. En particulier, un point de terminaison peut être en retard pour une retransmission spécifique en raison de son calendrier de sommeil et peut rattraper son retard lors de la suivante. Cependant, l'espacement minimum avant une autre retransmission est ACK_TIMEOUT, et la séquence entière de (re)transmissions DOIT rester dans l'enveloppe de MAX_TRANSMIT_SPAN (voir section 4.8.2), même si cela signifie qu'un expéditeur peut manquer une opportunité de transmettre.

Un point de terminaison CoAP qui a envoyé un message Confirmable PEUT abandonner sa tentative d'obtenir un ACK même avant que la valeur du compteur MAX_RETRANSMIT ne soit atteinte. Par exemple, l'application a annulé la requête car elle n'a plus besoin de réponse, ou il existe une autre indication que le message CON est bien arrivé. En particulier, un message de requête CoAP peut avoir suscité une réponse séparée, auquel cas il est clair pour le demandeur que seul l'ACK a été perdu et qu'une retransmission de la requête ne servirait à rien. Cependant, un répondeur NE DOIT PAS à son tour s'appuyer sur ce comportement inter-couches d'un demandeur, c'est-à-dire qu'il DOIT conserver l'état pour créer l'ACK pour la requête, si nécessaire, même si une réponse Confirmable a déjà été acquittée par le demandeur.

Une autre raison d'abandonner la retransmission PEUT être la réception d'erreurs ICMP. S'il est souhaité de tenir compte des erreurs ICMP, pour atténuer les attaques de spoofing potentielles, les implémentations DEVRAIENT veiller à vérifier les informations sur le datagramme original dans le message ICMP, y compris les numéros de port et les informations d'en-tête CoAP telles que le type et le code de message, le Message ID et le Token; si cela n'est pas possible en raison des limitations de l'API de service UDP, les erreurs ICMP DEVRAIENT être ignorées. Les erreurs Packet Too Big [RFC4443] ("fragmentation needed and DF set" pour IPv4 [RFC0792]) ne peuvent pas se produire correctement et DEVRAIENT être ignorées si la note d'implémentation de la section 4.6 est suivie; sinon, elles DEVRAIENT alimenter un algorithme de découverte de MTU de chemin [RFC4821]. Les messages ICMP Source Quench et Time Exceeded DEVRAIENT être ignorés. Les erreurs d'hôte, de réseau, de port ou de protocole inaccessible ou les erreurs de problème de paramètre PEUVENT, après un examen approprié, être utilisées pour informer l'application d'un échec d'envoi.

4.3. Messages Transmitted without Reliability (Messages transmis sans fiabilité)

Certains messages ne nécessitent pas d'accusé de réception. Ceci est particulièrement vrai pour les messages qui sont répétés régulièrement pour les besoins de l'application, tels que les lectures répétées d'un capteur où un succès éventuel est suffisant.

Comme alternative plus légère, un message peut être transmis de manière moins fiable en marquant le message comme Non-confirmable. Un message Non-confirmable porte toujours soit une requête soit une réponse et NE DOIT PAS être vide. Un message Non-confirmable NE DOIT PAS être acquitté par le destinataire. Un destinataire DOIT rejeter le message s'il manque de contexte pour traiter le message correctement, y compris le cas où le message est vide, utilise un code avec une classe réservée (1, 6 ou 7), ou a une erreur de format de message. Le rejet d'un message Non-confirmable PEUT impliquer l'envoi d'un message Reset correspondant, et à part le message Reset, le message rejeté DOIT être ignoré silencieusement.

Au niveau CoAP, il n'existe aucun moyen pour l'expéditeur de détecter si un message Non-confirmable a été reçu ou non. Un expéditeur PEUT choisir de transmettre plusieurs copies d'un message Non-confirmable dans MAX_TRANSMIT_SPAN (limité par les dispositions de la section 4.7, en particulier par PROBING_RATE si aucune réponse n'est reçue), ou le réseau peut dupliquer le message en transit. Pour permettre au récepteur d'agir une seule fois sur le message, les messages Non-confirmable spécifient également un Message ID. (Ce Message ID est tiré du même espace numérique que les Message ID pour les messages Confirmable.)

En résumant les sections 4.2 et 4.3, les quatre types de messages peuvent être utilisés comme dans le tableau 1. "*" signifie que la combinaison n'est pas utilisée en fonctionnement normal mais uniquement pour provoquer un message Reset ("CoAP ping").

               +----------+-----+-----+-----+-----+
               |          | CON | NON | ACK | RST |
               +----------+-----+-----+-----+-----+
               | Request  | X   | X   | -   | -   |
               | Response | X   | X   | X   | -   |
               | Empty    | *   | -   | X   | X   |
               +----------+-----+-----+-----+-----+

                  Tableau 1: Utilisation des types de messages

4.4. Message Correlation (Corrélation des messages)

Un message Acknowledgement ou Reset est corrélé avec un message Confirmable ou Non-confirmable au moyen du Message ID ainsi que des informations d'adresse supplémentaires du point de terminaison correspondant. Le Message ID est un entier non signé de 16 bits qui est généré par l'expéditeur d'un message Confirmable ou Non-confirmable et inclus dans l'en-tête CoAP. Le destinataire DOIT faire écho au Message ID dans le message Acknowledgement ou Reset.

Le même Message ID NE DOIT PAS être réutilisé (avec le même point de terminaison) dans EXCHANGE_LIFETIME (section 4.8.2).

Note d'implémentation: Plusieurs stratégies d'implémentation peuvent être utilisées pour générer les Message ID. Dans le cas le plus simple, un point de terminaison CoAP génère des Message ID en conservant une seule variable Message ID, qui est modifiée chaque fois qu'un nouveau message Confirmable ou Non-confirmable est envoyé, quelle que soit l'adresse ou le port de destination. Un point de terminaison qui doit gérer un grand nombre de transactions pourrait conserver plusieurs variables Message ID, par exemple, par préfixe ou adresse de destination. (Notez que certains points de terminaison de réception peuvent ne pas être en mesure de distinguer les paquets unicast et multicast qui lui sont adressés, donc les points de terminaison générant des Message ID doivent s'assurer que ceux-ci ne se chevauchent pas.) Il est fortement recommandé que la valeur initiale de la variable (par exemple, au démarrage) soit randomisée, afin de rendre moins probables les attaques hors chemin réussies sur le protocole.

Pour qu'un message Acknowledgement ou Reset corresponde à un message Confirmable ou Non-confirmable, le Message ID et le point de terminaison source du message Acknowledgement ou Reset DOIVENT correspondre au Message ID et au point de terminaison de destination du message Confirmable ou Non-confirmable.

4.5. Message Deduplication (Déduplication des messages)

Un destinataire peut recevoir le même message Confirmable (comme indiqué par le Message ID et le point de terminaison source) plusieurs fois dans EXCHANGE_LIFETIME (section 4.8.2), par exemple, lorsque son Acknowledgement a été perdu ou n'a pas atteint l'expéditeur d'origine avant le premier timeout. Le destinataire DEVRAIT acquitter chaque copie en double d'un message Confirmable en utilisant le même message Acknowledgement ou Reset, mais DEVRAIT traiter toute requête ou réponse dans le message une seule fois. L'assouplissement de cette règle dans le cas où la requête transmise dans le message Confirmable est idempotente (voir section 5.1) ou peut être gérée de manière idempotente est discuté dans la section suivante. Exemples de déduplication de messages assouplie:

• Un serveur peut assouplir l'exigence de répondre à toutes les retransmissions d'une requête idempotente avec la même réponse (section 4.2) afin qu'il n'ait pas à maintenir d'état pour le Message ID. Par exemple, une implémentation peut souhaiter traiter les transmissions en double d'une requête GET, PUT ou DELETE comme des requêtes séparées si la quantité de travail résultante est moins coûteuse que l'effort de suivi des réponses précédentes.

• Un serveur contraint peut même souhaiter assouplir cette exigence pour certaines requêtes non idempotentes si la sémantique d'application rend ce compromis favorable. Par exemple, si le résultat d'une requête POST est simplement la création d'un état de courte durée sur le serveur, il peut être moins coûteux d'engager cet effort plusieurs fois pour une requête que de suivre si une transmission antérieure de la même requête a déjà été traitée.

Un destinataire peut recevoir le même message Non-confirmable (comme indiqué par le Message ID et le point de terminaison source) plusieurs fois dans NON_LIFETIME (section 4.8.2). En règle générale (qui peut être assouplie en fonction de la sémantique spécifique d'un message), le destinataire DEVRAIT ignorer silencieusement tout message Non-confirmable en double et DEVRAIT traiter toute requête ou réponse dans le message une seule fois.

4.6. Message Size (Taille des messages)

Bien qu'il soit souhaitable que les messages tiennent dans un seul paquet IP (évitant la fragmentation IP), il s'agit d'une question de qualité d'implémentation. La spécification CoAP elle-même ne fournit qu'une limite supérieure pour la taille des messages. Les messages plus grands qu'un paquet IP entraînent une fragmentation de paquet indésirable. Un message CoAP, correctement encapsulé, DEVRAIT tenir dans un seul paquet IP (c'est-à-dire éviter la fragmentation IP) et (en tenant dans une charge utile UDP) doit évidemment tenir dans un seul datagramme IP. Si le Path MTU n'est pas connu, un IP MTU de 1280 octets DEVRAIT être supposé; si rien n'est connu sur la taille des en-têtes, de bonnes limites supérieures sont 1152 octets pour la taille du message et 1024 octets pour la taille de la charge utile.

Note d'implémentation: Le choix des paramètres de taille de message de CoAP fonctionne bien avec IPv6 et avec la plupart des chemins IPv4 d'aujourd'hui. (Cependant, avec IPv4, il est plus difficile de garantir absolument qu'il n'y a pas de fragmentation IP. S'il est essentiel de prendre en charge IPv4 dans des réseaux inhabituels, les implémentations peuvent vouloir se limiter à des tailles de datagramme IPv4 plus conservatrices telles que 576 octets; selon [RFC0791], le minimum absolu pour l'IP MTU dans IPv4 est aussi bas que 68 octets, ce qui ne laisserait que 40 octets moins les frais de sécurité pour la charge utile UDP. Les implémentations extrêmement axées sur cela peuvent également vouloir définir le bit DF IPv4 et effectuer une forme de découverte de MTU de chemin [RFC4821]; cependant, cela est généralement inutile dans les cas d'utilisation réalistes de CoAP.) Plus important dans de nombreux réseaux contraints est la fragmentation au niveau de la couche d'adaptation (par exemple, les paquets L2 6LoWPAN sont limités à 127 octets, y compris divers frais généraux); cela peut motiver les implémentations à être économes dans leurs tailles de paquets et à passer au transfert par blocs [BLOCK] lorsqu'elles approchent des tailles de message dans la plage à trois chiffres.

La taille des messages est également d'une importance considérable pour les implémenteurs sur les nœuds contraints. De nombreuses implémentations devront allouer un tampon pour les messages entrants. Si une implémentation est trop contrainte pour permettre l'allocation de la limite supérieure mentionnée ci-dessus, elle peut appliquer la stratégie d'implémentation suivante pour les messages n'utilisant pas la sécurité DTLS: L'implémentation qui reçoit un datagramme dans un tampon trop petit est normalement capable de déterminer si la fin du datagramme a été écartée et de récupérer la partie initiale. Ainsi, au moins l'en-tête CoAP et les options (sinon la totalité de la charge utile) sont susceptibles de tenir dans le tampon. Un serveur peut donc interpréter complètement la requête et renvoyer un code de réponse 4.13 (Request Entity Too Large; voir section 5.9.2.9) si la charge utile a été tronquée. Un client envoyant une requête idempotente et recevant une réponse plus grande que celle pouvant tenir dans son tampon peut répéter la requête avec une valeur appropriée pour l'option Block [BLOCK].

4.7. Congestion Control (Contrôle de congestion)

Le contrôle de congestion de base pour CoAP est fourni par le mécanisme de back-off exponentiel de la section 4.2.

Afin de ne pas provoquer de congestion, les clients (y compris les proxies) DOIVENT limiter strictement le nombre d'interactions en cours simultanées qu'ils maintiennent vers un serveur donné (y compris les proxies) à NSTART. Une interaction en cours est soit un CON (couche message) pour lequel un ACK n'a pas encore été reçu et est toujours en attente, soit une requête (correspondable par Message ID et token) pour laquelle ni une réponse ni un message Acknowledgement n'a encore été reçu et est toujours en attente (les deux peuvent se produire en même temps, comptant comme une interaction en cours). La valeur par défaut de NSTART dans cette spécification est 1.

D'autres optimisations et considérations de contrôle de congestion sont attendues à l'avenir, telles qu'une possible initialisation automatique des paramètres de transmission CoAP définis dans la section 4.8, ce qui pourrait alors également permettre des valeurs de NSTART supérieures à 1.

Après EXCHANGE_LIFETIME, un client cesse d'attendre une réponse à une requête Confirmable pour laquelle aucun message d'accusé de réception n'a été reçu. L'algorithme spécifique par lequel un client cesse "d'attendre" une réponse à une requête qui a été acquittée ou à une requête Non-confirmable n'est pas défini. Sauf modification par des optimisations de contrôle de congestion supplémentaires, il DOIT être choisi de telle sorte qu'un point de terminaison ne dépasse pas un débit de données moyen de PROBING_RATE lors de l'envoi à un autre point de terminaison qui ne répond pas.

Note: CoAP place la responsabilité du contrôle de congestion principalement sur les clients. Cependant, les clients peuvent mal fonctionner ou être en fait des attaquants, par exemple, pour effectuer des attaques d'amplification (section 11.3). Pour limiter les dommages (au réseau et à ses propres ressources énergétiques), un serveur DEVRAIT implémenter une certaine limitation de débit pour sa transmission de réponse basée sur des hypothèses raisonnables sur les exigences de l'application. Pour cela, un serveur PEUT employer des limiteurs de débit séparés pour différents services et ressources.

4.8. Transmission Parameters (Paramètres de transmission)

La transmission des messages est contrôlée par les paramètres suivants:

               +-------------------+---------------+
               | name              | default value |
               +-------------------+---------------+
               | ACK_TIMEOUT       | 2 seconds     |
               | ACK_RANDOM_FACTOR | 1.5           |
               | MAX_RETRANSMIT    | 4             |
               | NSTART            | 1             |
               | DEFAULT_LEISURE   | 5 seconds     |
               | PROBING_RATE      | 1 byte/second |
               +-------------------+---------------+

                 Tableau 2: Paramètres du protocole CoAP

4.8.1. Changing the Parameters (Modification des paramètres)

Les valeurs de ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, NSTART, DEFAULT_LEISURE (section 8.2) et PROBING_RATE peuvent être configurées avec des valeurs spécifiques à l'environnement d'application (y compris des valeurs ajustées dynamiquement); cependant, la méthode de configuration est hors de la portée de ce document. Il est RECOMMANDÉ qu'un environnement d'application utilise des valeurs cohérentes pour ces paramètres; les effets spécifiques du fonctionnement avec des valeurs incompatibles dans un environnement d'application sont en dehors de la portée de cette spécification.

Les paramètres de transmission ont été choisis pour obtenir un comportement sûr pour une utilisation sur Internet. Si la configuration souhaite utiliser des valeurs différentes, la configuration est responsable de s'assurer que ces propriétés de contrôle de congestion ne sont pas violées. En particulier, une diminution de ACK_TIMEOUT en dessous de 1 seconde violerait les directives de [RFC5405]. ([RTO-CONSIDER] fournit un contexte supplémentaire.) CoAP a été conçu pour permettre des implémentations qui ne maintiennent pas de mesures de temps aller-retour (RTT). Cependant, lorsqu'il existe un désir de diminuer significativement ACK_TIMEOUT ou d'augmenter NSTART, cela ne peut être fait en toute sécurité que lors du maintien de telles mesures. Une configuration NE DOIT PAS diminuer ACK_TIMEOUT ou augmenter NSTART sans utiliser de mécanismes qui garantissent la sécurité du contrôle de congestion, qui peuvent être définis soit dans la configuration, soit dans un futur document de normes.

ACK_RANDOM_FACTOR NE DOIT PAS être diminué en dessous de 1.0, et il DEVRAIT avoir une valeur suffisamment différente de 1.0 pour fournir une certaine protection contre les effets de synchronisation.

MAX_RETRANSMIT peut être ajusté librement, mais des valeurs plus faibles réduiront la probabilité qu'un message Confirmable soit effectivement reçu, tandis que des valeurs plus grandes que celles données ici nécessiteront des ajustements supplémentaires des valeurs de temps (voir section 4.8.2).

Si le choix des paramètres de transmission conduit à une augmentation des valeurs de temps dérivées (voir section 4.8.2), le mécanisme de configuration DOIT s'assurer que les valeurs ajustées sont également disponibles pour tous les points de terminaison qui doivent communiquer en utilisant ces valeurs ajustées.

4.8.2. Time Values Derived from Transmission Parameters (Valeurs de temps dérivées des paramètres de transmission)

La combinaison de ACK_TIMEOUT, ACK_RANDOM_FACTOR et MAX_RETRANSMIT influence le timing des retransmissions, ce qui à son tour influence la durée pendant laquelle certaines informations doivent être conservées par une implémentation. Pour pouvoir référencer sans ambiguïté ces valeurs de temps dérivées, nous leur donnons des noms comme suit:

MAX_TRANSMIT_SPAN: Temps maximum depuis la première transmission d'un message Confirmable jusqu'à sa dernière retransmission. Pour les paramètres de transmission par défaut, la valeur est (2+4+8+16)*1.5 = 45 secondes, ou plus généralement:

ACK_TIMEOUT * ((2 ** MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR

MAX_TRANSMIT_WAIT: Temps maximum depuis la première transmission d'un message Confirmable jusqu'au moment où l'expéditeur abandonne la réception d'un accusé de réception ou d'un reset. Pour les paramètres de transmission par défaut, la valeur est (2+4+8+16+32)*1.5 = 93 secondes, ou plus généralement:

ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR

De plus, certaines hypothèses doivent être faites sur les caractéristiques du réseau et des nœuds.

MAX_LATENCY: Temps maximum qu'un datagramme est censé prendre depuis le début de sa transmission jusqu'à l'achèvement de sa réception. Cette constante est liée au MSL (Maximum Segment Lifetime) de [RFC0793], qui est "arbitrairement défini comme étant de 2 minutes" (glossaire [RFC0793], page 81). Notez que ce n'est pas nécessairement plus petit que MAX_TRANSMIT_WAIT, car MAX_LATENCY n'est pas destiné à décrire une situation dans laquelle le protocole fonctionne bien, mais la situation dans le pire des cas contre laquelle le protocole doit se prémunir. Nous définissons également arbitrairement MAX_LATENCY à 100 secondes. Outre le fait d'être raisonnablement réaliste pour la plupart des configurations et proche du choix historique pour TCP, cette valeur permet également de représenter les temporisateurs de durée de vie des Message ID sur 8 bits (lorsqu'ils sont mesurés en secondes). Dans ces calculs, il n'y a aucune hypothèse selon laquelle la direction de transmission n'est pas pertinente (c'est-à-dire que le réseau est symétrique); il est simplement supposé que la même valeur peut raisonnablement être utilisée comme valeur maximale pour les deux directions. Si ce n'est pas le cas, les calculs suivants deviennent seulement légèrement plus complexes.

PROCESSING_DELAY: Le temps qu'un nœud prend pour transformer un message Confirmable en accusé de réception. Nous supposons que le nœud tentera d'envoyer un ACK avant que l'expéditeur n'expire, donc comme hypothèse conservatrice, nous le définissons égal à ACK_TIMEOUT.

MAX_RTT: Temps aller-retour maximum, ou:

(2 * MAX_LATENCY) + PROCESSING_DELAY

À partir de ces valeurs, nous pouvons dériver les valeurs suivantes pertinentes pour le fonctionnement du protocole:

EXCHANGE_LIFETIME: Temps depuis le début de l'envoi d'un message Confirmable jusqu'au moment où un accusé de réception n'est plus attendu, c'est-à-dire que les informations de couche message sur l'échange de messages peuvent être purgées. EXCHANGE_LIFETIME comprend un MAX_TRANSMIT_SPAN, une MAX_LATENCY pour la direction aller, PROCESSING_DELAY, et une MAX_LATENCY pour la direction retour. Notez que, si la configuration est choisie de telle sorte que la dernière période d'attente (qui est ACK_TIMEOUT * (2 ** MAX_RETRANSMIT) ou la différence entre MAX_TRANSMIT_SPAN et MAX_TRANSMIT_WAIT) est inférieure à MAX_LATENCY, alors MAX_TRANSMIT_WAIT n'a pas besoin d'être pris en compte -- un choix qui a été fait ici car MAX_LATENCY est une valeur dans le pire des cas qui est peu probable d'être rencontrée dans des couches inférieures réalistes. Dans ce cas, EXCHANGE_LIFETIME se simplifie en:

MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) + PROCESSING_DELAY

ou 247 secondes avec les paramètres de transmission par défaut.

NON_LIFETIME: Temps depuis l'envoi d'un message Non-confirmable jusqu'au moment où son Message ID peut être réutilisé en toute sécurité. Si la transmission multiple du message NON n'est pas utilisée, sa valeur est MAX_LATENCY, ou 100 secondes. Cependant, un expéditeur CoAP peut envoyer un message NON plusieurs fois, en particulier pour les applications multicast. Les implémentations qui ne suivent pas les messages NON en transit peuvent vouloir utiliser une valeur plus conservatrice. Bien que la spécification ne définisse pas de limite spécifique à cela, dans la plupart des cas, la détection fiable des doublons par le récepteur se fait à l'échelle de temps de MAX_TRANSMIT_SPAN. Par conséquent, pour cet objectif, il est plus sûr d'utiliser:

MAX_TRANSMIT_SPAN + MAX_LATENCY

ou 145 secondes avec les paramètres de transmission par défaut; cependant, une implémentation qui souhaite utiliser une seule valeur de timeout pour expirer les Message ID pour tous les types de messages peut utiliser en toute sécurité la valeur plus grande de EXCHANGE_LIFETIME.

Le tableau 3 répertorie les paramètres dérivés introduits dans cette sous-section ainsi que leurs valeurs par défaut.

               +-------------------+---------------+
               | name              | default value |
               +-------------------+---------------+
               | MAX_TRANSMIT_SPAN |          45 s |
               | MAX_TRANSMIT_WAIT |          93 s |
               | MAX_LATENCY       |         100 s |
               | PROCESSING_DELAY  |           2 s |
               | MAX_RTT           |         202 s |
               | EXCHANGE_LIFETIME |         247 s |
               | NON_LIFETIME      |         145 s |
               +-------------------+---------------+

               Tableau 3: Paramètres de protocole dérivés