CoRE Link-Format

CoRE (Constrained RESTful Environments) permette di realizzare l’architettura REST in una forma gestibile da nodi e reti a capacità limitata.

La scoperta di risorse fornite da un server Web HTTP è chiamata solitamente Web Discovery e la descrizione della relazione tra le risorse è chiamata Web Linking. Lo scopo finale quindi è quello di fornire URI per le risorse gestite dal server complementate da attributi su quelle risorse e possibili relazioni e collegamenti con ulteriori risorse.

Il CoRE Link-Format è inserito come payload e gli viene assegnato un Internet Media Type. Abbiamo un URI predefinita che è “/.well-known/core” che ci permette di avere un entry point predefinito per la richiesta della lista dei collegamenti sulle risorse gestite da un server (e quindi effettuare la discovery di risorse CoRE).

3.1.9.1.1 Discovery

Per fare discovery delle risorse su un server non bisogna far altro che inviare un messaggio GET “/.well-known/core” e il server restituirà un payload nel formato Core Link-Format. Il client poi successivamente andrà a fare un'operazione di match con il Resource Type appropriato, la descrizione dell'interfaccia e i tipi possibili di Media Type (RFC2045) per la sua applicazione.

È anche possibile utilizzare directory per la memorizzazione dei collegamenti alle varie risorse. Sono infatti presenti delle vere proprie entità che hanno al loro interno una gerarchia di altre entità e memorizzano i collegamenti alle risorse presenti sugli altri server.

3.1.9.1.2 Format

Il CoRE Link Format è in formato UTF-8. Ogni link descrive un URI all’interno di parentesi angolari (< … >).

Se è presente un parametro hosts indica che l’URI target è una risorsa gestita dal server. Il parametro anchor invece è utilizzato per descrivere le relazioni tra due risorse. Altri attributi utilizzati dal formato CoRE Link sono:

dipendente dall'applicazione a una risorsa.

• if (interface description) : è una stringa opaca utilizzata per fornire un nome o un URI

che indica un'interfaccia specifica utilizzata per interagire con la risorsa target e può essere riutilizzata da diversi rt.

• sz (maximum size estimate) : fornisce un'indicazione della dimensione massima della

rappresentazione della risorsa restituita da un'operazione di GET su un URI target. Non dovrebbe essere utilizzato per risorse molto piccole che possono rientrare in una singola MTU e comunque non è definito un limite superiore.

Per quanto riguarda invece le risorse disponibile al path /.well-known/, dipende tutto

dall'applicazione l'organizzazione dei collegamenti all'interno di questo percorso. È possibile comunque effettuare operazioni di filtering per quanto riguarda i vari attributi.

Nel caso di nodi dalla capacità limitata possono anche non supportarlo e devono semplicemente ignorare la stringa di filtering e restituire l'intera risorsa.

3.1.9.1.3 Esempi

Questo esempio collega due differenti sensori che condividono la stessa descrizione dell'interfaccia (if=“sensors”):

Dispone la descrizione dei collegamenti in modo gerarchico e include un collegamento ad una sottorisorsa che contiene i collegamenti sui sensori.

3.1.9.1.4 Considerazioni sulla sicurezza

La risorsa /.well-known/core potrebbe essere protetta utilizzando DTLS quando viene fatto l’hosting su un server. Si potrebbe fornire il discovery delle risorse su differenti livelli. Alcuni nodi potrebbero effettuare la scrittura di un particolare stato sulla risorsa mentre tutti gli altri hanno solo il permesso di lettura.

Le richieste in multicast sulle risorse well-known possono essere utilizzate per effettuare attacchi di tipo DoS su dispositivi di capacità limitata. Per ovviare a questo problema una richiesta multicast deve essere sufficientemente autenticata e messa in sicurezza (utilizzando ad esempio IPSec).

3.2. MQTT

MQTT è l’acronimo di MQ Telemetry Transport ed è un protocollo di messaging leggero, basato sull’utilizzo di broker secondo il modello publish-subscribe.

Queste caratteristiche lo rendono adatto all’utilizzo in ambienti constrained dove ad esempio abbiamo una gestione della rete molto costosa, banda limitata, la comunicazione non è affidabile oppure ci sono dispositivi con processori e risorse di memoria limitate. Queste invece sono le caratteristiche principali:

• Pattern di messaggistica publish-subscribe che permette la distribuzione uno a molti dei messaggi e il disaccoppiamento delle applicazioni.

• Il livello di trasporto per il messaging non considera il contenuto del payload. • L’utilizzo di TCP-IP permette di ottenere connettività di rete di base.

• Abbiamo tre tipi di QoS per la delivery dei messaggi:

1. At most once : i messaggi sono consegnati secondo la modalità best effort della

rete TCP-IP sottostante. Può esserci sia duplicazione che perdita di messaggi. Questa modalità può essere usata con sensori di ambiente dove non importa se una lettura venga persa dato che poi ne verrà pubblicata una subito dopo. 2. At least once : si ha la consegna garantita del messaggio ma si potrebbe avere

un’eventuale duplicazione.

3. Exactly once : si ha la garanzia che i messaggi arrivino esattamente una volta

sola. Questa modalità può essere utilizzata in quei casi in cui dobbiamo effettuare operazioni di billing ed è importante che non ci siano ne duplicati e ne perdite di messaggi.

• Un overhead a livello di trasporto molto basso con un header di soli 2 byte e scambi di protocollo minimizzati per ridurre il traffico di rete.

• Un meccanismo per notificare le parti interessate di una disconnessione anormale di un client, utilizzando la caratteristica Last Will and Testament.

Nell’ultima versione disponibile (3.1) sono state introdotte alcune funzionalità e

ottimizzazioni come la possibilità di inviare username e password all’interno di un pacchetto CONNECT, miglioramenti per la sicurezza con codici restituiti dall’invio di pacchetti

3.2.1. Architettura

MQTT è basato sul modello publish-subscribe. È message oriented e ogni messaggio è pubblicato su un indirizzo (il topic). I client possono comunque sottoscriversi a topic multipli e successivamente ognuno riceverà tutti i messaggi diretti verso il topic scelto.

Ad esempio consideriamo il caso in cui abbiamo 3 client (A, B e C) che hanno connessioni TCP aperte con il broker MQTT. B e C si sottoscrivono al topic “temperature”:

Successivamente A pubblica il valore 25 sul topic. Il broker allora effettua il forwarding dei messaggi ai client sottoscritti.

3.2.2. Messaggi