4. Message Transmission (Trasmissione dei messaggi)

I messaggi CoAP vengono scambiati in modo asincrono tra endpoint CoAP. Vengono utilizzati per trasportare richieste e risposte CoAP, la cui semantica è definita nella sezione 5.

Poiché CoAP è legato a trasporti inaffidabili come UDP, i messaggi CoAP possono arrivare fuori sequenza, apparire duplicati o andare persi senza preavviso. Per questo motivo, CoAP implementa un meccanismo di affidabilità leggero, senza cercare di ricreare l'insieme completo di funzionalità di un trasporto come TCP. Ha le seguenti caratteristiche:

• Affidabilità di ritrasmissione stop-and-wait semplice con back-off esponenziale per i messaggi Confirmable.

• Rilevamento dei duplicati sia per i messaggi Confirmable che Non-confirmable.

4.1. Messages and Endpoints (Messaggi ed endpoint)

Un endpoint CoAP è la sorgente o la destinazione di un messaggio CoAP. La definizione specifica di un endpoint dipende dal trasporto utilizzato per CoAP. Per i trasporti definiti in questa specifica, l'endpoint è identificato a seconda della modalità di sicurezza utilizzata (vedere sezione 9): Senza sicurezza, l'endpoint è identificato esclusivamente da un indirizzo IP e un numero di porta UDP. Con altre modalità di sicurezza, l'endpoint è identificato come definito dalla modalità di sicurezza.

Esistono diversi tipi di messaggi. Il tipo di un messaggio è specificato dal campo Type dell'intestazione CoAP.

Separatamente dal tipo di messaggio, un messaggio può contenere una richiesta, una risposta o essere vuoto (Empty). Questo è segnalato dal campo Request/Response Code nell'intestazione CoAP ed è rilevante per il modello richiesta/risposta. I valori possibili per il campo sono mantenuti nei registri dei codici CoAP (sezione 12.1).

Un messaggio vuoto ha il campo Code impostato su 0.00. Il campo Token Length DEVE essere impostato su 0 e i byte di dati NON DEVONO essere presenti dopo il campo Message ID. Se sono presenti byte, DEVONO essere elaborati come un errore di formato del messaggio.

4.2. Messages Transmitted Reliably (Messaggi trasmessi in modo affidabile)

La trasmissione affidabile di un messaggio viene avviata contrassegnando il messaggio come Confirmable nell'intestazione CoAP. Un messaggio Confirmable trasporta sempre una richiesta o una risposta, a meno che non venga utilizzato solo per sollecitare un messaggio Reset, nel qual caso è vuoto. Un destinatario DEVE (a) confermare un messaggio Confirmable con un messaggio Acknowledgement o (b) rifiutare il messaggio se il destinatario manca del contesto per elaborare correttamente il messaggio, incluse le situazioni in cui il messaggio è vuoto, utilizza un codice con una classe riservata (1, 6 o 7), o presenta un errore di formato del messaggio. Il rifiuto di un messaggio Confirmable viene effettuato inviando un messaggio Reset corrispondente e ignorandolo altrimenti. Il messaggio Acknowledgement DEVE restituire il Message ID del messaggio Confirmable e DEVE trasportare una risposta o essere vuoto (vedere sezioni 5.2.1 e 5.2.2). Il messaggio Reset DEVE restituire il Message ID del messaggio Confirmable e DEVE essere vuoto. Il rifiuto di un messaggio Acknowledgement o Reset (incluso il caso in cui l'Acknowledgement trasporta una richiesta o un codice con una classe riservata, o il messaggio Reset non è vuoto) viene effettuato ignorandolo silenziosamente. Più in generale, i destinatari dei messaggi Acknowledgement e Reset NON DEVONO rispondere con messaggi Acknowledgement o Reset.

Il mittente ritrasmette il messaggio Confirmable a intervalli esponenzialmente crescenti, fino a quando non riceve un riconoscimento (o messaggio Reset) o esaurisce i tentativi.

La ritrasmissione è controllata da due elementi che un endpoint CoAP DEVE tenere traccia per ogni messaggio Confirmable che invia mentre attende un riconoscimento (o reset): un timeout e un contatore di ritrasmissione. Per un nuovo messaggio Confirmable, il timeout iniziale è impostato su una durata casuale (spesso non un numero intero di secondi) tra ACK_TIMEOUT e (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (vedere sezione 4.8), e il contatore di ritrasmissione è impostato su 0. Quando il timeout viene attivato e il contatore di ritrasmissione è inferiore a MAX_RETRANSMIT, il messaggio viene ritrasmesso, il contatore di ritrasmissione viene incrementato e il timeout viene raddoppiato. Se il contatore di ritrasmissione raggiunge MAX_RETRANSMIT con un timeout, o se l'endpoint riceve un messaggio Reset, allora il tentativo di trasmettere il messaggio viene annullato e il processo dell'applicazione viene informato del fallimento. D'altra parte, se l'endpoint riceve un riconoscimento in tempo, la trasmissione è considerata riuscita.

Questa specifica non impone requisiti stringenti sull'accuratezza degli orologi utilizzati per implementare l'algoritmo di back-off esponenziale binario sopra descritto. In particolare, un endpoint può essere in ritardo per una ritrasmissione specifica a causa del suo programma di sospensione e può recuperare nella successiva. Tuttavia, la spaziatura minima prima di un'altra ritrasmissione è ACK_TIMEOUT, e l'intera sequenza di (ri)trasmissioni DEVE rimanere nell'involucro di MAX_TRANSMIT_SPAN (vedere sezione 4.8.2), anche se ciò significa che un mittente può perdere un'opportunità di trasmettere.

Un endpoint CoAP che ha inviato un messaggio Confirmable PUÒ rinunciare al tentativo di ottenere un ACK anche prima che venga raggiunto il valore del contatore MAX_RETRANSMIT. Ad esempio, l'applicazione ha annullato la richiesta poiché non ha più bisogno di una risposta, o c'è qualche altra indicazione che il messaggio CON è arrivato. In particolare, un messaggio di richiesta CoAP può aver suscitato una risposta separata, nel qual caso è chiaro per il richiedente che solo l'ACK è andato perso e una ritrasmissione della richiesta non avrebbe scopo. Tuttavia, un risponditore NON DEVE a sua volta fare affidamento su questo comportamento cross-layer da parte di un richiedente, cioè, DEVE conservare lo stato per creare l'ACK per la richiesta, se necessario, anche se una risposta Confirmable è già stata confermata dal richiedente.

Un altro motivo per rinunciare alla ritrasmissione PUÒ essere la ricezione di errori ICMP. Se si desidera tenere conto degli errori ICMP, per mitigare potenziali attacchi di spoofing, le implementazioni DOVREBBERO prestare attenzione a verificare le informazioni sul datagramma originale nel messaggio ICMP, inclusi i numeri di porta e le informazioni dell'intestazione CoAP come tipo e codice del messaggio, Message ID e Token; se ciò non è possibile a causa delle limitazioni dell'API del servizio UDP, gli errori ICMP DOVREBBERO essere ignorati. Gli errori Packet Too Big [RFC4443] ("fragmentation needed and DF set" per IPv4 [RFC0792]) non possono verificarsi correttamente e DOVREBBERO essere ignorati se viene seguito il nota di implementazione nella sezione 4.6; altrimenti, DOVREBBERO alimentare un algoritmo di scoperta MTU del percorso [RFC4821]. I messaggi ICMP Source Quench e Time Exceeded DOVREBBERO essere ignorati. Gli errori di host, rete, porta o protocollo irraggiungibile o gli errori di problema dei parametri POSSONO, dopo un'adeguata verifica, essere utilizzati per informare l'applicazione di un fallimento nell'invio.

4.3. Messages Transmitted without Reliability (Messaggi trasmessi senza affidabilità)

Alcuni messaggi non richiedono un riconoscimento. Questo è particolarmente vero per i messaggi che vengono ripetuti regolarmente per i requisiti dell'applicazione, come le letture ripetute da un sensore dove un successo eventuale è sufficiente.

Come alternativa più leggera, un messaggio può essere trasmesso in modo meno affidabile contrassegnando il messaggio come Non-confirmable. Un messaggio Non-confirmable trasporta sempre una richiesta o una risposta e NON DEVE essere vuoto. Un messaggio Non-confirmable NON DEVE essere confermato dal destinatario. Un destinatario DEVE rifiutare il messaggio se manca del contesto per elaborare correttamente il messaggio, incluso il caso in cui il messaggio è vuoto, utilizza un codice con una classe riservata (1, 6 o 7), o presenta un errore di formato del messaggio. Il rifiuto di un messaggio Non-confirmable PUÒ comportare l'invio di un messaggio Reset corrispondente, e a parte il messaggio Reset, il messaggio rifiutato DEVE essere ignorato silenziosamente.

A livello CoAP, non c'è modo per il mittente di rilevare se un messaggio Non-confirmable è stato ricevuto o meno. Un mittente PUÒ scegliere di trasmettere più copie di un messaggio Non-confirmable entro MAX_TRANSMIT_SPAN (limitato dalle disposizioni della sezione 4.7, in particolare da PROBING_RATE se non viene ricevuta alcuna risposta), o la rete può duplicare il messaggio in transito. Per consentire al ricevitore di agire solo una volta sul messaggio, i messaggi Non-confirmable specificano anche un Message ID. (Questo Message ID è tratto dallo stesso spazio numerico dei Message ID per i messaggi Confirmable.)

Riassumendo le sezioni 4.2 e 4.3, i quattro tipi di messaggi possono essere utilizzati come nella tabella 1. "*" significa che la combinazione non viene utilizzata in operazioni normali ma solo per sollecitare un messaggio Reset ("CoAP ping").

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

                  Tabella 1: Uso dei tipi di messaggio

4.4. Message Correlation (Correlazione dei messaggi)

Un messaggio Acknowledgement o Reset è correlato con un messaggio Confirmable o Non-confirmable per mezzo del Message ID insieme alle informazioni di indirizzo aggiuntive dell'endpoint corrispondente. Il Message ID è un intero senza segno a 16 bit generato dal mittente di un messaggio Confirmable o Non-confirmable e incluso nell'intestazione CoAP. Il destinatario DEVE restituire il Message ID nel messaggio Acknowledgement o Reset.

Lo stesso Message ID NON DEVE essere riutilizzato (con lo stesso endpoint) entro EXCHANGE_LIFETIME (sezione 4.8.2).

Nota di implementazione: È possibile impiegare diverse strategie di implementazione per generare Message ID. Nel caso più semplice, un endpoint CoAP genera Message ID mantenendo una singola variabile Message ID, che viene modificata ogni volta che viene inviato un nuovo messaggio Confirmable o Non-confirmable, indipendentemente dall'indirizzo o dalla porta di destinazione. Un endpoint che deve gestire un gran numero di transazioni potrebbe mantenere più variabili Message ID, ad esempio, una per prefisso o indirizzo di destinazione. (Si noti che alcuni endpoint riceventi potrebbero non essere in grado di distinguere i pacchetti unicast e multicast a loro indirizzati, quindi gli endpoint che generano Message ID devono assicurarsi che questi non si sovrappongano.) Si raccomanda vivamente che il valore iniziale della variabile (ad esempio, all'avvio) sia randomizzato, al fine di rendere meno probabili gli attacchi off-path riusciti sul protocollo.

Perché un messaggio Acknowledgement o Reset corrisponda a un messaggio Confirmable o Non-confirmable, il Message ID e l'endpoint sorgente del messaggio Acknowledgement o Reset DEVONO corrispondere al Message ID e all'endpoint di destinazione del messaggio Confirmable o Non-confirmable.

4.5. Message Deduplication (Deduplicazione dei messaggi)

Un destinatario potrebbe ricevere lo stesso messaggio Confirmable (come indicato dal Message ID e dall'endpoint sorgente) più volte entro EXCHANGE_LIFETIME (sezione 4.8.2), ad esempio, quando il suo Acknowledgement è andato perso o non ha raggiunto il mittente originale prima del primo timeout. Il destinatario DOVREBBE confermare ogni copia duplicata di un messaggio Confirmable utilizzando lo stesso messaggio Acknowledgement o Reset, ma DOVREBBE elaborare qualsiasi richiesta o risposta nel messaggio solo una volta. Il rilassamento di questa regola nel caso in cui la richiesta trasmessa nel messaggio Confirmable sia idempotente (vedere sezione 5.1) o possa essere gestita in modo idempotente è discusso nella sezione successiva. Esempi di deduplicazione dei messaggi rilassata:

• Un server potrebbe rilassare il requisito di rispondere a tutte le ritrasmissioni di una richiesta idempotente con la stessa risposta (sezione 4.2) in modo da non dover mantenere lo stato per il Message ID. Ad esempio, un'implementazione potrebbe voler trattare le trasmissioni duplicate di una richiesta GET, PUT o DELETE come richieste separate se la quantità di lavoro risultante è meno costosa dello sforzo di tenere traccia delle risposte precedenti.

• Un server vincolato potrebbe persino voler rilassare questo requisito per alcune richieste non idempotenti se la semantica dell'applicazione rende favorevole questo compromesso. Ad esempio, se il risultato di una richiesta POST è solo la creazione di uno stato di breve durata sul server, potrebbe essere meno costoso sostenere questo sforzo più volte per una richiesta piuttosto che tenere traccia se una trasmissione precedente della stessa richiesta è già stata elaborata.

Un destinatario potrebbe ricevere lo stesso messaggio Non-confirmable (come indicato dal Message ID e dall'endpoint sorgente) più volte entro NON_LIFETIME (sezione 4.8.2). Come regola generale (che può essere rilassata in base alla semantica specifica di un messaggio), il destinatario DOVREBBE ignorare silenziosamente qualsiasi messaggio Non-confirmable duplicato e DOVREBBE elaborare qualsiasi richiesta o risposta nel messaggio solo una volta.

4.6. Message Size (Dimensione del messaggio)

Sebbene sia desiderabile che i messaggi rientrino in un singolo pacchetto IP (evitando la frammentazione IP), questa è una questione di qualità dell'implementazione. La specifica CoAP stessa fornisce solo un limite superiore per la dimensione del messaggio. I messaggi più grandi di un pacchetto IP comportano una frammentazione di pacchetto indesiderabile. Un messaggio CoAP, opportunamente incapsulato, DOVREBBE rientrare in un singolo pacchetto IP (cioè, evitare la frammentazione IP) e (rientrando in un payload UDP) ovviamente deve rientrare in un singolo datagramma IP. Se la MTU del percorso non è nota, DOVREBBE essere assunta una MTU IP di 1280 byte; se non si sa nulla sulle dimensioni delle intestazioni, buoni limiti superiori sono 1152 byte per la dimensione del messaggio e 1024 byte per la dimensione del payload.

Nota di implementazione: La scelta dei parametri di dimensione del messaggio di CoAP funziona bene con IPv6 e con la maggior parte dei percorsi IPv4 odierni. (Tuttavia, con IPv4, è più difficile garantire assolutamente che non ci sia frammentazione IP. Se è essenziale supportare IPv4 in reti insolite, le implementazioni potrebbero volersi limitare a dimensioni di datagramma IPv4 più conservative come 576 byte; secondo [RFC0791], il minimo assoluto per la MTU IP in IPv4 è di soli 68 byte, il che lascerebbe solo 40 byte meno l'overhead di sicurezza per il payload UDP. Le implementazioni estremamente focalizzate su questo potrebbero anche voler impostare il bit DF di IPv4 ed eseguire qualche forma di scoperta MTU del percorso [RFC4821]; tuttavia, questo è generalmente non necessario nei casi d'uso realistici di CoAP.) Più importante in molte reti vincolate è la frammentazione a livello di adattamento (ad esempio, i pacchetti L2 6LoWPAN sono limitati a 127 byte inclusi vari overhead); questo può motivare le implementazioni ad essere parsimoniose nelle dimensioni dei pacchetti e a passare al trasferimento a blocchi [BLOCK] quando si avvicinano dimensioni di messaggio nell'intervallo a tre cifre.

La dimensione del messaggio è anche di notevole importanza per gli implementatori su nodi vincolati. Molte implementazioni dovranno allocare un buffer per i messaggi in arrivo. Se un'implementazione è troppo vincolata per consentire l'allocazione del limite superiore sopra menzionato, può applicare la seguente strategia di implementazione per i messaggi che non utilizzano la sicurezza DTLS: L'implementazione che riceve un datagramma in un buffer troppo piccolo è normalmente in grado di determinare se la coda del datagramma è stata scartata e di recuperare la parte iniziale. Quindi almeno l'intestazione CoAP e le opzioni (se non l'interezza del payload) sono probabilmente adatte al buffer. Un server può quindi interpretare completamente la richiesta e restituire un codice di risposta 4.13 (Request Entity Too Large; vedere sezione 5.9.2.9) se il payload è stato troncato. Un client che invia una richiesta idempotente e riceve una risposta più grande di quella che può contenere nel suo buffer può ripetere la richiesta con un valore appropriato per l'opzione Block [BLOCK].

4.7. Congestion Control (Controllo della congestione)

Il controllo base della congestione per CoAP è fornito dal meccanismo di back-off esponenziale nella sezione 4.2.

Per non causare congestione, i client (inclusi i proxy) DEVONO limitare rigorosamente il numero di interazioni in sospeso simultanee che mantengono verso un determinato server (inclusi i proxy) a NSTART. Un'interazione in sospeso è un CON (livello messaggio) per il quale non è stato ancora ricevuto un ACK e si sta ancora aspettando, o una richiesta (abbinabile per Message ID e token) per la quale non è stata ancora ricevuta né una risposta né un messaggio Acknowledgement e si sta ancora aspettando (entrambi possono verificarsi contemporaneamente, contando come un'interazione in sospeso). Il valore predefinito per NSTART in questa specifica è 1.

Si prevede in futuro ulteriori ottimizzazioni e considerazioni sul controllo della congestione, come una possibile inizializzazione automatica dei parametri di trasmissione CoAP definiti nella sezione 4.8, che potrebbero quindi consentire anche valori di NSTART maggiori di 1.

Dopo EXCHANGE_LIFETIME, un client smette di aspettarsi una risposta a una richiesta Confirmable per la quale non è stato ricevuto alcun messaggio di riconoscimento. L'algoritmo specifico mediante il quale un client smette di "aspettarsi" una risposta a una richiesta che è stata confermata o a una richiesta Non-confirmable non è definito. A meno che non sia modificato da ulteriori ottimizzazioni del controllo della congestione, DEVE essere scelto in modo tale che un endpoint non superi una velocità dati media di PROBING_RATE nell'invio a un altro endpoint che non risponde.

Nota: CoAP pone l'onere del controllo della congestione principalmente sui client. Tuttavia, i client possono funzionare male o essere effettivamente attaccanti, ad esempio, per eseguire attacchi di amplificazione (sezione 11.3). Per limitare il danno (alla rete e alle proprie risorse energetiche), un server DOVREBBE implementare una qualche limitazione della velocità per la sua trasmissione di risposta basata su ipotesi ragionevoli sui requisiti dell'applicazione. Per questo, un server PUÒ impiegare limitatori di velocità separati per diversi servizi e risorse.

4.8. Transmission Parameters (Parametri di trasmissione)

La trasmissione dei messaggi è controllata dai seguenti parametri:

               +-------------------+---------------+
               | 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 |
               +-------------------+---------------+

                 Tabella 2: Parametri del protocollo CoAP

4.8.1. Changing the Parameters (Modifica dei parametri)

I valori per ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, NSTART, DEFAULT_LEISURE (sezione 8.2) e PROBING_RATE possono essere configurati con valori specifici per l'ambiente applicativo (inclusi valori dinamicamente adattati); tuttavia, il metodo di configurazione è al di fuori dell'ambito di questo documento. Si RACCOMANDA che un ambiente applicativo utilizzi valori coerenti per questi parametri; gli effetti specifici dell'operare con valori incompatibili in un ambiente applicativo sono al di fuori dell'ambito di questa specifica.

I parametri di trasmissione sono stati scelti per ottenere un comportamento sicuro per l'uso su Internet. Se la configurazione desidera utilizzare valori diversi, la configurazione è responsabile di garantire che queste proprietà di controllo della congestione non vengano violate. In particolare, una diminuzione di ACK_TIMEOUT al di sotto di 1 secondo violerebbe le linee guida di [RFC5405]. ([RTO-CONSIDER] fornisce ulteriore contesto.) CoAP è stato progettato per consentire implementazioni che non mantengono misurazioni del tempo di andata e ritorno (RTT). Tuttavia, quando esiste il desiderio di diminuire significativamente ACK_TIMEOUT o aumentare NSTART, ciò può essere fatto in modo sicuro solo quando si mantengono tali misurazioni. Una configurazione NON DEVE diminuire ACK_TIMEOUT o aumentare NSTART senza utilizzare meccanismi che garantiscono la sicurezza del controllo della congestione, che possono essere definiti nella configurazione o in un futuro documento di standard.

ACK_RANDOM_FACTOR NON DEVE essere diminuito al di sotto di 1.0, e DOVREBBE avere un valore sufficientemente diverso da 1.0 per fornire una certa protezione dagli effetti di sincronizzazione.

MAX_RETRANSMIT può essere regolato liberamente, ma valori più bassi ridurranno la probabilità che un messaggio Confirmable venga effettivamente ricevuto, mentre valori più grandi di quelli qui indicati richiederanno ulteriori regolazioni ai valori temporali (vedere sezione 4.8.2).

Se la scelta dei parametri di trasmissione porta a un aumento dei valori temporali derivati (vedere sezione 4.8.2), il meccanismo di configurazione DEVE garantire che i valori regolati siano disponibili anche per tutti gli endpoint che devono comunicare utilizzando questi valori regolati.

4.8.2. Time Values Derived from Transmission Parameters (Valori temporali derivati dai parametri di trasmissione)

La combinazione di ACK_TIMEOUT, ACK_RANDOM_FACTOR e MAX_RETRANSMIT influenza i tempi delle ritrasmissioni, che a loro volta influenzano per quanto tempo alcune informazioni devono essere conservate da un'implementazione. Per poter fare riferimento in modo univoco a questi valori temporali derivati, diamo loro nomi come segue:

MAX_TRANSMIT_SPAN: Tempo massimo dalla prima trasmissione di un messaggio Confirmable alla sua ultima ritrasmissione. Per i parametri di trasmissione predefiniti, il valore è (2+4+8+16)*1.5 = 45 secondi, o più in generale:

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

MAX_TRANSMIT_WAIT: Tempo massimo dalla prima trasmissione di un messaggio Confirmable al momento in cui il mittente rinuncia a ricevere un riconoscimento o reset. Per i parametri di trasmissione predefiniti, il valore è (2+4+8+16+32)*1.5 = 93 secondi, o più in generale:

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

Inoltre, è necessario fare alcune ipotesi sulle caratteristiche della rete e dei nodi.

MAX_LATENCY: Tempo massimo che un datagramma dovrebbe impiegare dall'inizio della sua trasmissione al completamento della sua ricezione. Questa costante è correlata al MSL (Maximum Segment Lifetime) di [RFC0793], che è "arbitrariamente definito come 2 minuti" (glossario [RFC0793], pagina 81). Si noti che questo non è necessariamente inferiore a MAX_TRANSMIT_WAIT, poiché MAX_LATENCY non è inteso per descrivere una situazione in cui il protocollo funziona bene, ma la situazione nel caso peggiore contro cui il protocollo deve proteggersi. Definiamo anche arbitrariamente MAX_LATENCY come 100 secondi. Oltre ad essere ragionevolmente realistico per la maggior parte delle configurazioni e vicino alla scelta storica per TCP, questo valore consente anche ai timer di durata del Message ID di essere rappresentati in 8 bit (quando misurati in secondi). In questi calcoli, non si presume che la direzione di trasmissione sia irrilevante (cioè, che la rete sia simmetrica); si presume semplicemente che lo stesso valore possa essere ragionevolmente utilizzato come valore massimo per entrambe le direzioni. Se così non fosse, i calcoli seguenti diventano solo leggermente più complessi.

PROCESSING_DELAY: Il tempo che un nodo impiega per trasformare un messaggio Confirmable in un riconoscimento. Presumiamo che il nodo tenterà di inviare un ACK prima del timeout del mittente, quindi come ipotesi conservativa lo impostiamo uguale a ACK_TIMEOUT.

MAX_RTT: Tempo massimo di andata e ritorno, o:

(2 * MAX_LATENCY) + PROCESSING_DELAY

Da questi valori, possiamo derivare i seguenti valori rilevanti per il funzionamento del protocollo:

EXCHANGE_LIFETIME: Tempo dall'inizio dell'invio di un messaggio Confirmable al momento in cui un riconoscimento non è più atteso, cioè, le informazioni del livello messaggio sullo scambio di messaggi possono essere eliminate. EXCHANGE_LIFETIME include un MAX_TRANSMIT_SPAN, una MAX_LATENCY per la direzione in avanti, PROCESSING_DELAY e una MAX_LATENCY per la direzione di ritorno. Si noti che, se la configurazione è scelta in modo tale che l'ultimo periodo di attesa (che è ACK_TIMEOUT * (2 ** MAX_RETRANSMIT) o la differenza tra MAX_TRANSMIT_SPAN e MAX_TRANSMIT_WAIT) sia inferiore a MAX_LATENCY, allora MAX_TRANSMIT_WAIT non deve essere preso in considerazione -- una scelta che è stata fatta qui poiché MAX_LATENCY è un valore del caso peggiore che è improbabile incontrare in livelli inferiori realistici. In questo caso, EXCHANGE_LIFETIME si semplifica in:

MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) + PROCESSING_DELAY

o 247 secondi con i parametri di trasmissione predefiniti.

NON_LIFETIME: Tempo dall'invio di un messaggio Non-confirmable al momento in cui il suo Message ID può essere riutilizzato in sicurezza. Se non viene utilizzata la trasmissione multipla del messaggio NON, il suo valore è MAX_LATENCY, o 100 secondi. Tuttavia, un mittente CoAP può inviare un messaggio NON più volte, in particolare per applicazioni multicast. Le implementazioni che non tengono traccia dei messaggi NON in transito potrebbero voler utilizzare un valore più conservativo. Sebbene la specifica non definisca un limite specifico su questo, nella maggior parte dei casi, il rilevamento affidabile dei duplicati da parte del ricevitore avviene sulla scala temporale di MAX_TRANSMIT_SPAN. Pertanto, per questo scopo, è più sicuro utilizzare:

MAX_TRANSMIT_SPAN + MAX_LATENCY

o 145 secondi con i parametri di trasmissione predefiniti; tuttavia, un'implementazione che desidera utilizzare un singolo valore di timeout per far scadere i Message ID per tutti i tipi di messaggio può utilizzare in sicurezza il valore più grande di EXCHANGE_LIFETIME.

La tabella 3 elenca i parametri derivati introdotti in questa sottosezione insieme ai loro valori predefiniti.

               +-------------------+---------------+
               | 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 |
               +-------------------+---------------+

               Tabella 3: Parametri di protocollo derivati