8. Multicast CoAP (CoAP Multicast)

CoAP supporta l'invio di richieste a un gruppo multicast IP. Questo è definito da una serie di delta al CoAP unicast. Una discussione più generale sulla comunicazione di gruppo CoAP è fornita in [GROUPCOMM].

Un endpoint CoAP che fornisce un servizio scopribile da altri endpoint utilizzando la scoperta del servizio multicast si unisce a uno o più degli indirizzi multicast all-CoAP-nodes appropriati (Sezione 12.8) e ascolta sulla porta CoAP predefinita. Si noti che un endpoint può ricevere richieste multicast su altri indirizzi multicast (incluso l'indirizzo IPv6 all-nodes) o tramite broadcast su IPv4; pertanto, un endpoint DEVE essere preparato a ricevere tali messaggi ma PUÒ ignorarli se la scoperta del servizio multicast non è desiderata.

8.1. Messaging Layer (Livello di Messaggistica)

Una richiesta multicast è caratterizzata dall'essere trasportata in un messaggio CoAP indirizzato a un indirizzo multicast IP invece che a un endpoint CoAP. Tali richieste multicast DEVONO essere Non-confirmable.

Un server DOVREBBE essere consapevole che una richiesta è arrivata tramite multicast, ad esempio utilizzando API moderne come IPV6_RECVPKTINFO [RFC3542], se disponibili.

Per evitare un'implosione di risposte di errore, quando un server è consapevole che una richiesta è arrivata tramite multicast, NON DEVE restituire un messaggio Reset in risposta a un messaggio Non-confirmable. Se non lo sa, PUÒ restituire un messaggio Reset in risposta a un messaggio Non-confirmable come al solito. Poiché tale messaggio Reset apparirà identico a uno inviato per un messaggio unicast al mittente, il mittente DEVE evitare di utilizzare ID di messaggio che sono anche ancora attivi da questo endpoint con qualsiasi endpoint che potrebbe ricevere il messaggio multicast.

Al momento della scrittura, i messaggi multicast possono essere trasportati solo in UDP e non in DTLS. Ciò significa che le modalità di sicurezza definite in questo documento per CoAP non si applicano al multicast.

8.2. Request/Response Layer (Livello Richiesta/Risposta)

Quando un server è consapevole che una richiesta è arrivata tramite multicast, il server PUÒ sempre ignorare la richiesta, in particolare se non ha una risposta utile (ad esempio, se avrebbe solo un payload vuoto o una risposta di errore). Questa decisione può dipendere dall'applicazione. (Ad esempio, nel filtraggio delle query descritto in [RFC6690], il server non risponde a una richiesta multicast se il filtro non corrisponde. Altri esempi sono in [GROUPCOMM].)

Se un server decide di rispondere a una richiesta multicast, NON DOVREBBE rispondere immediatamente. Invece, DOVREBBE scegliere una durata per il periodo di tempo durante il quale intende rispondere. Ai fini di questa esposizione, chiamiamo la lunghezza di questo periodo Leisure. Il valore specifico di questo Leisure può dipendere dall'applicazione o PUÒ essere derivato come descritto di seguito. Il server DOVREBBE quindi scegliere un punto temporale casuale all'interno del periodo di leisure scelto per inviare la risposta unicast alla richiesta multicast. Se è necessario inviare ulteriori risposte basate sulla stessa appartenenza all'indirizzo multicast, un nuovo periodo di leisure inizia al più presto dopo il completamento del precedente.

Per calcolare un valore per Leisure, il server DOVREBBE avere una stima della dimensione del gruppo G, un tasso di trasferimento dati target R (entrambi scelti in modo conservativo) e una dimensione di risposta stimata S; un limite inferiore approssimativo per Leisure può quindi essere calcolato come

lb_Leisure = S * G / R

Ad esempio, per una richiesta multicast con ambito locale di collegamento su una rete 2.4 GHz IEEE 802.15.4 (6LoWPAN), G può essere (relativamente conservativamente) impostato a 100, S impostato a 100 byte e il tasso target a 8 kbit/s = 1 kB/s. Il limite inferiore risultante per il Leisure è di 10 s.

Se un endpoint CoAP non ha dati appropriati per calcolare un valore per Leisure, PUÒ ricorrere a DEFAULT_LEISURE.

Quando si abbina una risposta a una richiesta multicast, solo il token DEVE corrispondere; l'endpoint di origine della risposta non deve (e non sarà) essere lo stesso dell'endpoint di destinazione della richiesta originale.

Ai fini dell'interpretazione delle opzioni Location-* e di qualsiasi collegamento incorporato nella rappresentazione, l'URI della richiesta (cioè l'URI di base relativo al quale viene interpretata la risposta) è formato sostituendo l'indirizzo multicast nel componente Host dell'URI della richiesta originale con l'indirizzo IP letterale dell'endpoint che effettivamente risponde.

8.2.1. Caching (Memorizzazione nella Cache)

Quando un client effettua una richiesta multicast, effettua sempre una nuova richiesta al gruppo multicast (poiché potrebbero esserci nuovi membri del gruppo che si sono uniti nel frattempo o che non hanno ricevuto la richiesta precedente). PUÒ aggiornare una cache con le risposte ricevute. Utilizza quindi sia le risposte memorizzate nella cache-ancora fresche sia quelle nuove come risultato della richiesta.

Una risposta ricevuta in risposta a una richiesta GET a un gruppo multicast PUÒ essere utilizzata per soddisfare una richiesta successiva sull'URI di richiesta unicast correlato. L'URI di richiesta unicast si ottiene sostituendo la parte di autorità dell'URI di richiesta con l'indirizzo di origine del livello di trasporto del messaggio di risposta.

Una cache PUÒ rivalidare una risposta effettuando una richiesta GET sull'URI di richiesta unicast correlato.

Una richiesta GET a un gruppo multicast NON DEVE contenere un'opzione ETag. Il meccanismo per sopprimere le risposte che il client ha già è lasciato a studi futuri.

8.2.2. Proxying (Uso del Proxy)

Quando un proxy forward riceve una richiesta con un Proxy-Uri o un URI costruito da Proxy-Scheme che indica un indirizzo multicast, il proxy ottiene un insieme di risposte come descritto sopra e invia tutte le risposte (sia memorizzate nella cache-ancora fresche sia nuove) al client originale.

Questa specifica non fornisce alcun modo per indicare l'URI di richiesta modificato-unicast (URI di base) nelle risposte così inoltrate. L'uso del proxy per le richieste multicast è discusso più dettagliatamente in [GROUPCOMM]; un modo per affrontare il problema dell'URI di base può essere trovato nella Sezione 3 di [CoAP-MISC].