1. Introduzione

Il lavoro su ambienti RESTful vincolati (CoRE) mira a realizzare l'architettura Representational State Transfer (REST) in una forma adatta per i nodi più vincolati (come microcontrollori con RAM e ROM limitate [RFC7228]) e reti (come IPv6 su Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944]) [RFC7252]. Il protocollo CoAP è destinato a fornire servizi RESTful [REST] non dissimili da HTTP [RFC7230], riducendo al contempo la complessità di implementazione e la dimensione dei pacchetti scambiati al fine di rendere questi servizi utili in una rete altamente vincolata di nodi altamente vincolati.

Questo obiettivo richiede moderazione in una serie di modi a volte contrastanti:

ridurre la complessità di implementazione al fine di ridurre al minimo la dimensione del codice,
ridurre le dimensioni dei messaggi al fine di ridurre al minimo il numero di frammenti necessari per ogni messaggio (per massimizzare la probabilità di consegna del messaggio), la quantità di potenza di trasmissione necessaria e il carico del canale a larghezza di banda limitata,
ridurre i requisiti sull'ambiente come archiviazione stabile, buone fonti di casualità o capacità di interazione con l'utente.

Poiché CoAP si basa su trasporti datagramma come UDP o Datagram Transport Layer Security (DTLS), la dimensione massima delle rappresentazioni delle risorse che possono essere trasferite senza troppa frammentazione è limitata. Inoltre, non tutte le rappresentazioni delle risorse si adatteranno a un singolo pacchetto a livello di collegamento di una rete vincolata, il che potrebbe causare la frammentazione del livello di adattamento anche se la frammentazione del livello IP non è richiesta. L'uso della frammentazione (sia a livello di adattamento che a livello IP) per il trasporto di rappresentazioni più grandi sarebbe possibile fino alla dimensione massima del protocollo datagramma sottostante (come UDP), ma il processo di frammentazione/riassemblaggio grava sui livelli inferiori con uno stato di conversazione che è meglio gestito nel livello applicativo.

La presente specifica definisce una coppia di opzioni CoAP per consentire l'accesso a blocchi alle rappresentazioni delle risorse. Le opzioni Block forniscono un modo minimo per trasferire rappresentazioni di risorse più grandi in modo frammentato (a blocchi). L'obiettivo principale è evitare la necessità di creare uno stato di conversazione sul server per le richieste GET a blocchi. (È impossibile evitare completamente di creare uno stato di conversazione per POST/PUT, se la creazione/sostituzione delle risorse deve essere atomica; laddove tale proprietà non è necessaria, non è necessario creare uno stato di conversazione del server nemmeno in questo caso.)

I trasferimenti a blocchi sono realizzati come combinazioni di scambi, ciascuno dei quali viene eseguito secondo il protocollo base CoAP [RFC7252]. Ogni scambio in tale combinazione è regolato dalle specifiche in [RFC7252], incluse le specifiche di controllo della congestione (Sezione 4.7 di [RFC7252]) e le considerazioni sulla sicurezza (Sezione 11 di [RFC7252]; ulteriori considerazioni sulla sicurezza si applicano quindi ai trasferimenti nel loro complesso, vedere Sezione 7). La presente specifica riduce al minimo i vincoli che aggiunge a quegli scambi di base; tuttavia, non tutte le varianti di utilizzo di CoAP sono molto utili all'interno di un trasferimento a blocchi (ad esempio, l'utilizzo di richieste non confermabili all'interno di trasferimenti a blocchi al di fuori del caso d'uso della Sezione 2.8 aumenterebbe la probabilità complessiva di mancata consegna). Per essere perfettamente chiari, la presente specifica non rimuove nemmeno alcuno dei vincoli posti dalla specifica di base su cui è rigorosamente stratificata. Ad esempio, i pacchetti back-to-back sono limitati dal controllo della congestione descritto nella Sezione 4.7 di [RFC7252] (NSTART come limite per l'avvio degli scambi, PROBING_RATE come limite per l'invio senza risposta); i trasferimenti a blocchi non possono inviare/sollecitare più traffico di quanto un client potrebbe inviare / sollecitare dallo stesso server senza la modalità a blocchi.

In alcuni casi, la presente specifica RACCOMANDERÀ che un client esegua una sequenza di trasferimenti a blocchi "senza indebito ritardo". Questo non può essere formulato come un requisito di interoperabilità, ma è un'aspettativa sulla qualità dell'implementazione. Al contrario, l'aspettativa è che i server non debbano fare i salti mortali per accogliere i client che impiegano molto tempo per completare un trasferimento a blocchi. Ad esempio, per un GET a blocchi, se la risorsa cambia mentre questo procede, l'entity-tag (ETag) per un ulteriore blocco ottenuto potrebbe essere diverso. Per evitare che ciò accada continuamente per una risorsa che cambia rapidamente, un server PUÒ (MAY) provare a mantenere una cache per un client specifico per un breve periodo di tempo. L'attente aspettativa qui è che la durata di tale cache possa essere mantenuta breve, nell'ordine di alcuni tempi di andata e ritorno previsti, contando dal precedente blocco trasferito.

In sintesi, questa specifica aggiunge una coppia di opzioni Block a CoAP che possono essere utilizzate per i trasferimenti a blocchi. I vantaggi dell'utilizzo di queste opzioni includono:

I trasferimenti più grandi di quelli che possono essere ospitati nei pacchetti a livello di collegamento di rete vincolata possono essere eseguiti in blocchi più piccoli.
Nessuno stato di conversazione difficile da gestire viene creato a livello di adattamento o a livello IP per la frammentazione.
Il trasferimento di ogni blocco viene confermato, consentendo la ritrasmissione individuale se necessario.
Entrambe le parti hanno voce in capitolo sulla dimensione del blocco che verrà effettivamente utilizzata.
Gli scambi risultanti sono facili da capire utilizzando strumenti di analisi dei pacchetti e quindi abbastanza accessibili per il debug.
Se necessario, le opzioni Block possono essere utilizzate anche (senza modifiche) per fornire un accesso casuale a blocchi di dimensioni potenza di due all'interno di una rappresentazione di risorsa.

Un'implementazione CoAP che non supporta queste opzioni è generalmente limitata nella dimensione delle rappresentazioni che possono essere scambiate, vedere la Sezione 4.6 di [RFC7252]. Anche se le opzioni sono Critiche, un server può decidere di iniziare a utilizzarle in modo non richiesto in una risposta (Block2) a una richiesta che non conteneva un'opzione Block.