2. Constrained Application Protocol (Protocollo di applicazione vincolato)
Il modello di interazione di CoAP è simile al modello client/server di HTTP. Tuttavia, le interazioni machine-to-machine tipicamente risultano in un'implementazione CoAP che agisce sia nel ruolo di client che di server. Una richiesta CoAP è equivalente a quella di HTTP ed è inviata da un client per richiedere un'azione (utilizzando un Method Code) su una risorsa (identificata da un URI) su un server. Il server quindi invia una risposta con un Response Code; 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, Non-confirmable, Acknowledgement, Reset. I Method Code e i Response Code inclusi in alcuni di questi messaggi li fanno trasportare 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 Acknowledgement.
Si potrebbe pensare a CoAP logicamente come utilizzando 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 Method e Response Code (vedi Figura 1). CoAP è tuttavia un singolo protocollo, con messaggistica e richiesta/risposta come semplici caratteristiche dell'intestazione CoAP.
+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+
Figura 1: Stratificazione astratta di CoAP
2.1. Messaging Model (Modello di messaggistica)
Il modello di messaggistica CoAP si basa sullo scambio di messaggi su UDP tra endpoint.
CoAP utilizza un'intestazione binaria breve di 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 Message ID utilizzato per rilevare duplicati e per l'affidabilità opzionale. (Il Message ID è compatto; la sua dimensione di 16 bit consente fino a circa 250 messaggi al secondo da un endpoint all'altro con i parametri di protocollo predefiniti.)
L'affidabilità viene fornita contrassegnando un messaggio come Confirmable (CON). Un messaggio Confirmable viene ritrasmesso utilizzando un timeout predefinito e un back-off esponenziale tra le ritrasmissioni, fino a quando il destinatario invia un messaggio Acknowledgement (ACK) con lo stesso Message ID (in questo esempio, 0x7d34) dall'endpoint corrispondente; vedi Figura 2. Quando un destinatario non è affatto in grado di elaborare un messaggio Confirmable (cioè, non è nemmeno in grado di fornire una risposta di errore appropriata), risponde con un messaggio Reset (RST) invece di un Acknowledgement (ACK).
Client Server
| |
| CON [0x7d34] |
+----------------->|
| |
| ACK [0x7d34] |
|<-----------------+
| |
Figura 2: Trasmissione di messaggi affidabile
Un messaggio che non richiede trasmissione affidabile (ad esempio, ogni singola misurazione da un flusso di dati del sensore) può essere inviato come un messaggio Non-confirmable (NON). Questi non vengono riconosciuti, ma hanno comunque un Message ID per il rilevamento dei duplicati (in questo esempio, 0x01a0); vedi Figura 3. Quando un destinatario non è in grado di elaborare un messaggio Non-confirmable, può rispondere con un messaggio Reset (RST).
Client Server
| |
| NON [0x01a0] |
+----------------->|
| |
Figura 3: Trasmissione di messaggi non affidabile
Vedi Sezione 4 per i dettagli dei messaggi CoAP.
Poiché CoAP funziona su UDP, supporta anche l'uso di indirizzi IP di destinazione multicast, abilitando richieste CoAP multicast. La Sezione 8 discute l'uso appropriato dei messaggi CoAP con indirizzi multicast e 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. Request/Response Model (Modello richiesta/risposta)
La semantica delle richieste e risposte CoAP è trasportata nei messaggi CoAP, che includono rispettivamente un Method Code o un Response Code. Le informazioni di richiesta e risposta opzionali (o predefinite), 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). (Si noti che il Token è un concetto separato dal Message ID.)
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 Acknowledgement (ACK) risultante. Questo è chiamato risposta piggyback, dettagliato nella Sezione 5.2.1. (Non è necessario riconoscere separatamente una risposta piggyback, poiché il client ritrasmetterà la richiesta se il messaggio Acknowledgement che trasporta la risposta piggyback viene perso.) Due esempi per una richiesta GET di base con risposta piggyback sono mostrati nella Figura 4, uno riuscito, uno che risulta 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 piggyback
Se il server non è in grado di rispondere immediatamente a una richiesta trasportata in un messaggio Confirmable, risponde semplicemente con un messaggio Acknowledgement vuoto in modo che il client possa smettere di ritrasmettere la richiesta. Quando la risposta è pronta, il server la invia in un nuovo messaggio Confirmable (che quindi deve essere riconosciuto dal client). Questo è chiamato "risposta separata", come illustrato nella Figura 5 e descritto più in dettaglio nella Sezione 5.2.2.
Client Server
| |
| CON [0x7a10] |
| GET /temperature |
| (Token 0x73) |
+----------------->|
| |
| ACK [0x7a10] |
|<-----------------+
| |
... Il 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, allora 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-confirmable
CoAP fa uso dei metodi GET, PUT, POST e DELETE in modo simile a HTTP, con la semantica specificata nella Sezione 5.8. (Si noti che la semantica dettagliata dei metodi CoAP è "quasi, ma non del tutto diversa" [HHGTTG] da quella dei metodi HTTP: l'intuizione presa dall'esperienza HTTP generalmente si applica 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, utilizzando valori predefiniti per l'efficienza. I Response Code 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. Intermediaries and Caching (Intermediari e caching)
Il protocollo supporta il caching delle risposte per soddisfare efficientemente le richieste. Il caching semplice è abilitato utilizzando 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 di dispositivi in modalità sleep e per ragioni 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. Vedi Sezione 5.7 per ulteriori informazioni sulla funzionalità del proxy.
Poiché CoAP è stato progettato secondo l'architettura REST [REST], e quindi presenta funzionalità simili a quelle del protocollo HTTP, è piuttosto 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 eseguita da un proxy cross-protocollo ("cross-proxy"), che converte il Method o Response Code, il tipo di media e le opzioni nella corrispondente caratteristica HTTP e viceversa. La Sezione 10 fornisce maggiori dettagli sulla mappatura HTTP.
2.4. Resource Discovery (Scoperta delle risorse)
La scoperta delle risorse è importante per le interazioni machine-to-machine ed è supportata utilizzando il CoRE Link Format [RFC6690] che è discusso nella Sezione 7.