2. Protocollo applicativo vincolato
Il modello di interazione di CoAP è simile al modello client/server di HTTP. Tuttavia, le interazioni machine-to-machine in genere comportano un'implementazione CoAP che agisce sia nei ruoli di client che di server. Una richiesta CoAP è equivalente a quella di HTTP e viene inviata da un client per richiedere un'azione (utilizzando un codice metodo) su una risorsa (identificata da un URI) su un server. Il server invia quindi una risposta con un codice di risposta; questa risposta può includere una rappresentazione della risorsa.
A differenza di HTTP, CoAP gestisce questi scambi in modo asincrono su un trasporto orientato ai datagrammi come UDP. Ciò viene fatto logicamente utilizzando un livello di messaggi che supporta l'affidabilità opzionale (con back-off esponenziale). CoAP definisce quattro tipi di messaggi: Confirmable (Confermabile), Non-confirmable (Non confermabile), Acknowledgement (Conferma), Reset (Ripristino). I codici metodo e i codici di risposta inclusi in alcuni di questi messaggi fanno sì che essi trasportino richieste o risposte. Gli scambi di base dei quattro tipi di messaggi sono in qualche modo ortogonali alle interazioni richiesta/risposta; le richieste possono essere trasportate in messaggi Confirmable e Non-confirmable, e le risposte possono essere trasportate in questi così come in piggyback nei messaggi di Acknowledgement.
Si potrebbe pensare a CoAP logicamente come all'utilizzo di un approccio a due livelli, un livello di messaggistica CoAP utilizzato per gestire UDP e la natura asincrona delle interazioni, e le interazioni richiesta/risposta utilizzando codici metodo e di risposta (vedere Figura 1). CoAP è tuttavia un singolo protocollo, con messaggistica e richiesta/risposta come semplici funzionalità dell'intestazione CoAP.
+----------------------+
| Applicazione |
+----------------------+
+----------------------+ \
| Richieste/Risposte | |
|----------------------| | CoAP
| Messaggi | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Figura 1: Stratificazione astratta di CoAP
2.1. Modello di messaggistica
Il modello di messaggistica CoAP si basa sullo scambio di messaggi su UDP tra endpoint.
CoAP utilizza una breve intestazione binaria a lunghezza fissa (4 byte) che può essere seguita da opzioni binarie compatte e un payload. Questo formato di messaggio è condiviso da richieste e risposte. Il formato del messaggio CoAP è specificato nella Sezione 3. Ogni messaggio contiene un ID messaggio utilizzato per rilevare i duplicati e per l'affidabilità opzionale. (L'ID messaggio è compatto; la sua dimensione di 16 bit consente fino a circa 250 messaggi al secondo da un endpoint all'altro con parametri di protocollo predefiniti.)
L'affidabilità è fornita contrassegnando un messaggio come Confirmable (CON). Un messaggio Confirmable viene ritrasmesso utilizzando un timeout predefinito e un back-off esponenziale tra le ritrasmissioni, finché il destinatario non invia un messaggio di Acknowledgement (ACK) con lo stesso ID messaggio (in questo esempio, 0x7d34) dall'endpoint corrispondente; vedere Figura 2. Quando un destinatario non è affatto in grado di elaborare un messaggio Confirmable (ovvero, non è nemmeno in grado di fornire una risposta di errore adeguata), risponde con un messaggio di Reset (RST) invece di un Acknowledgement (ACK).
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Figura 2: Trasmissione affidabile dei messaggi
Un messaggio che non richiede una trasmissione affidabile (ad esempio, ogni singola misurazione da un flusso di dati del sensore) può essere inviato come messaggio Non-confirmable (NON). Questi non vengono confermati, ma hanno comunque un ID messaggio per il rilevamento dei duplicati (in questo esempio, 0x01a0); vedere Figura 3. Quando un destinatario non è in grado di elaborare un messaggio Non-confirmable, può rispondere con un messaggio di Reset (RST).
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
Figura 3: Trasmissione inaffidabile dei messaggi
Vedere la Sezione 4 per i dettagli sui messaggi CoAP.
Poiché CoAP viene eseguito su UDP, supporta anche l'uso di indirizzi IP di destinazione multicast, consentendo richieste CoAP multicast. La Sezione 8 discute l'uso corretto dei messaggi CoAP con indirizzi multicast e le precauzioni per evitare la congestione delle risposte.
Diverse modalità di sicurezza sono definite per CoAP nella Sezione 9, che vanno da nessuna sicurezza alla sicurezza basata su certificati. Questo documento specifica un binding a DTLS per proteggere il protocollo; l'uso di IPsec con CoAP è discusso in [IPsec-CoAP].
2.2. Modello richiesta/risposta
La semantica di richiesta e risposta CoAP è trasportata nei messaggi CoAP, che includono rispettivamente un codice metodo o un codice di risposta. Le informazioni opzionali (o predefinite) di richiesta e risposta, come l'URI e il tipo di media del payload, sono trasportate come opzioni CoAP. Un token viene utilizzato per abbinare le risposte alle richieste indipendentemente dai messaggi sottostanti (Sezione 5.3). (Notare che il token è un concetto separato dall'ID messaggio.)
Una richiesta viene trasportata in un messaggio Confirmable (CON) o Non-confirmable (NON) e, se immediatamente disponibile, la risposta a una richiesta trasportata in un messaggio Confirmable viene trasportata nel messaggio di Acknowledgement (ACK) risultante. Questa è chiamata risposta piggybacked, dettagliata nella Sezione 5.2.1. (Non è necessario confermare separatamente una risposta piggybacked, poiché il client ritrasmetterà la richiesta se il messaggio di Acknowledgement che trasporta la risposta piggybacked viene perso.) Due esempi per una richiesta GET di base con risposta piggybacked sono mostrati nella Figura 4, una riuscita, una risultante in una risposta 4.04 (Not Found).
Client Server Client Server
| | | |
| CON [0xbc90] | | CON [0xbc91] |
| GET /temperature | | GET /temperature |
| (Token 0x71) | | (Token 0x72) |
+----------------->| +----------------->|
| | | |
| ACK [0xbc90] | | ACK [0xbc91] |
| 2.05 Content | | 4.04 Not Found |
| (Token 0x71) | | (Token 0x72) |
| "22.5 C" | | "Not found" |
|<-----------------+ |<-----------------+
| | | |
Figura 4: Due richieste GET con risposte piggybacked
Se il server non è in grado di rispondere immediatamente a una richiesta trasportata in un messaggio Confirmable, risponde semplicemente con un messaggio di Acknowledgement vuoto in modo che il client possa interrompere la ritrasmissione della richiesta. Quando la risposta è pronta, il server la invia in un nuovo messaggio Confirmable (che a sua volta deve essere confermato dal client). Questa è chiamata "risposta separata", come illustrato nella Figura 5 e descritto in maggiore dettaglio nella Sezione 5.2.2.
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Tempo passa ...
| |
| CON [0x23bb] |
| 2.05 Content |
| (Token 0x73) |
| "22.5 C" |
|<-----------------+
| |
| ACK [0x23bb] |
+----------------->|
| |
Figura 5: Una richiesta GET con una risposta separata
Se una richiesta viene inviata in un messaggio Non-confirmable, la risposta viene inviata utilizzando un nuovo messaggio Non-confirmable, sebbene il server possa invece inviare un messaggio Confirmable. Questo tipo di scambio è illustrato nella Figura 6.
Client Server
| |
| NON [0x7a11] |
| GET /temperature |
| (Token 0x74) |
+----------------->|
| |
| NON [0x23bc] |
| 2.05 Content |
| (Token 0x74) |
| "22.5 C" |
|<-----------------+
| |
Figura 6: Una richiesta e una risposta trasportate in messaggi
non confermabili
CoAP fa uso dei metodi GET, PUT, POST e DELETE in modo simile a HTTP, con la semantica specificata nella Sezione 5.8. (Notare che la semantica dettagliata dei metodi CoAP è "quasi, ma non del tutto diversa" [HHGTTG] da quella dei metodi HTTP: l'intuizione tratta dall'esperienza HTTP si applica generalmente bene, ma ci sono abbastanza differenze da rendere utile leggere effettivamente la presente specifica.)
Metodi oltre ai quattro di base possono essere aggiunti a CoAP in specifiche separate. I nuovi metodi non devono necessariamente utilizzare richieste e risposte in coppia. Anche per i metodi esistenti, una singola richiesta può produrre più risposte, ad esempio per una richiesta multicast (Sezione 8) o con l'opzione Observe [OBSERVE].
Il supporto URI in un server è semplificato poiché il client analizza già l'URI e lo divide in componenti host, porta, percorso e query, facendo uso di valori predefiniti per l'efficienza. I codici di risposta si riferiscono a un piccolo sottoinsieme di codici di stato HTTP con alcuni codici specifici di CoAP aggiunti, come definito nella Sezione 5.9.
2.3. Intermediari e caching
Il protocollo supporta il caching delle risposte per soddisfare in modo efficiente le richieste. Il caching semplice è abilitato utilizzando le informazioni di freschezza e validità trasportate con le risposte CoAP. Una cache potrebbe essere situata in un endpoint o in un intermediario. La funzionalità di caching è specificata nella Sezione 5.6.
Il proxying è utile nelle reti vincolate per diversi motivi, tra cui limitare il traffico di rete, migliorare le prestazioni, accedere alle risorse dei dispositivi dormienti e per motivi di sicurezza. Il proxying delle richieste per conto di un altro endpoint CoAP è supportato nel protocollo. Quando si utilizza un proxy, l'URI della risorsa da richiedere è incluso nella richiesta, mentre l'indirizzo IP di destinazione è impostato sull'indirizzo del proxy. Vedere la Sezione 5.7 per ulteriori informazioni sulla funzionalità proxy.
Poiché CoAP è stato progettato secondo l'architettura REST [REST] e quindi presenta funzionalità simili a quelle del protocollo HTTP, è abbastanza semplice mappare da CoAP a HTTP e da HTTP a CoAP. Tale mappatura può essere utilizzata per realizzare un'interfaccia REST HTTP utilizzando CoAP o per convertire tra HTTP e CoAP. Questa conversione può essere effettuata da un proxy cross-protocol ("cross-proxy"), che converte il codice metodo o di risposta, il tipo di media e le opzioni nella funzionalità HTTP corrispondente. La Sezione 10 fornisce maggiori dettagli sulla mappatura HTTP.
2.4. Discovery delle risorse
Il discovery delle risorse è importante per le interazioni machine-to-machine ed è supportato utilizzando il formato di collegamento CoRE [RFC6690] come discusso nella Sezione 7.