MASTER UNIVERSITARIO DI II LIVELLO 'INTERNET OF THINGS AND BIG DATA'' - A.A. 2018-2019 - MASTER IOT AND BIG DATA
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Master Universitario di II Livello ’Internet of Things and Big Data’’ – A.A. 2018-2019
1
9/6/18 5454
9/6/18
Per andare incontro alle esigenze dei sistemi IoT è in
via di definizione uno stack di protocol standard che
integra i protocolli web che tutti conosciamo (HTTP
ecc),
Nello Stack IoT alcuni fattori comuni a molte
applicazioni (discovery, push notification ecc) sono
state integrate a livello applicativo (e quindi
vengono fornite come primitive di protocolli come
MQTT, XMPP ed altri)
5555
9/6/18 5656
9/6/18
Facciamo un confronto tra protocolli web tradizionali
come Rest/HTTP e i nuovi standard per IoT.
Nel protocollo REST si utilizzano i metodi HTTP
(Get, Post, ecc) per accedere a risorse su server
remoti identificati da indirizzi simbolici (URI).
Indirizzi URI sono gestiti da database distribuiti (DNS)
che fungono da yellowpage (mappano nomi
simbolici in indirizzi IP)
Il protocollo HTTP permette di accedere in maniera
sincrona (request/response) ad una risorsa remota
(pagina web)
5757
9/6/18
Il formato dei dati usati da HTTP è principalmente
XML e JSON.
5858
9/6/18
REST è basato sui metodi HTTP
5959
9/6/18
Ecco alcuni esempi di metodi GET e POST
6060
9/6/18
Ecco un altro esempio di uso di GET (per aggiornare
info sul server e quindi con side-effect) e POST
(con body del messaggio formattato con XML)
6161
9/6/18
I server REST sono tipicamente stateless cioè non
mantengono informazioni di stato tra diverse
sessioni HTTP. I Server stateless sono più semplici
da
implementare (ogni sessione è indipendente
dall’altra). Le informazioni di stato si possono anche
memorizzare nei dati scambiati attraverso i metodi
GET/POST oppure usando cookie o altre
estensioni fornite dai browser.
62629/6/18
Gli indirizzi URI hanno una struttura che ricorda i
pathname del file system.
63639/6/18
Gli indirizzi URI hanno una struttura che ricorda i
pathname del file system.
64649/6/18
Vediamo ora uno scenario semplice di interazione
con un sensore attraverso REST.
Supponiamo di voler leggere i dati di un sensore
collegato (non ci interessa come) ad una macchina
con un server web.
Il client deve effettuare polling HTTP per chiedere il
valore del sensore. Ogni lettura richiede una
sessione HTTP (che ha diverse fasi di handshaking
per stabilire la connessione tra endpoint seguite da
invio della richiesta e ricezione dei dati).
Questo tipo di interazione può generare un
eccessivo consumo energetico sul controller del
device (es. Raspberry alimentato a batteria
collegato ad un sensore di temperatura).
65659/6/18
Il client deve effettuare polling HTTP per chiedere il
valore del sensore.
66669/6/18
Ogni lettura richiede una sessione HTTP (che ha
diverse fasi di handshaking per stabilire la
connessione tra endpoint seguite da invio della
richiesta e ricezione dei dati).
Questo tipo di interazione può generare un
eccessivo consumo energetico sul controller del
device (es. Raspberry alimentato a batteria
collegato ad un sensore di temperatura).
676768 68
9/6/18
Il protocollo CoAP (Constrained Application Protocol)
è stato introdotto da IETF per situazioni in cui può
essere utile interagire in maniera più flessibile con
un server,
69699/6/18
CoAP può essere interpretato come un protocollo
REST su UDP. Supporta operazioni di discovery di
risorse su un server (richiesta di meta dati al
server), sottoscrizione per ricezioni di update dei
valori di risorse del server (ed dati di una variabile
attraverso push notification), caching, e proxy
HTTP
70709/6/18
CoAP può essere integrato con HTTP attraverso
opportuni Proxy per costruire reti ibride.
71719/6/18
CoAP supporta transazioni asincrone, messaggi con
e senza conferma (ack) e altre ottimizzazioni (es.
trasferimento di blocchi, ecc)
72729/6/18
CoAP può essere integrato con HTTP attraverso
opportuni Proxy per costruire reti ibride.
73739/6/18
CoAP può essere integrato con HTTP attraverso
opportuni Proxy per costruire reti ibride.
74749/6/18
CoAP può essere integrato con HTTP attraverso
opportuni Proxy per costruire reti ibride.
75759/6/18
Le richieste CoAP possono richiedere ACK ed essere
gestite in maniera sincrona o asincrona
76769/6/18
Ecco un esempio di transazione asincrona con
messaggio che richiede ACK. Assumiamo quindi
che il server abbia bisogno di elaborare la richiesta
Senza bloccare il client. In questo caso il client usa
un token univoco per fare matching tra richiesta e
ack.
77779/6/18
Stop and wait disciplina tentativi di ritrasmissione per
messaggi con conferma per i quali non si riceve
ACK dopo un certo tempo massimo (time-out)
78789/6/18
La modalità Observation viene usata per evitare
polling e ricevere invece update di dati di risorse
(es sensori) gestiti dal server CoAP
79799/6/18
La modalità Observation in azione con messaggi con
conferma (ACK)
80809/6/18
La richiesta “wellknown” invia al client la lista di
risorse gestite dal CoAP server (a partire dalla
quale il client può inviare richieste specifiche).
Ad esempio il server potrebbe inviare la lista di tutte
le variabili che rappresentano dati di sensori
collegati al server CoAP
81819/6/18
La richiesta “wellknown” invia al client la lista di
risorse gestite dal CoAP server (a partire dalla
quale il client può inviare richieste specifiche).
Ad esempio il server potrebbe inviare la lista di tutte
le variabili che rappresentano dati di sensori
collegati al server CoAP
82829/6/18
La richiesta “wellknown” invia al client la lista di
risorse gestite dal CoAP server (a partire dalla
quale il client può inviare richieste specifiche).
Ad esempio il server potrebbe inviare la lista di tutte
le variabili che rappresentano dati di sensori
collegati al server CoAP
83839/6/18
ì
84849/6/18 8585
86 86
9/6/18 8787
9/6/18
MQTT è un protocollo molto “leggero” (nel senso che
richiede poche risorse sia per eseguire server sia
per scambiare dati) pensato per comunicazione tra
smart object (Machine to Machine, M2M) di basso
costo e potenza. Il Broker MQTT funge da
coordinatore per update su canali (topic) che
vengono usati per inviare update a tutti i client
interessati (notifiche push come nelle news/feed)
88889/6/18
MQTT è un protocollo molto “leggero” (nel senso che
richiede poche risorse sia per eseguire server sia
per scambiare dati) pensato per comunicazione tra
smart object (Machine to Machine, M2M) di basso
costo e potenza. Il Broker MQTT funge da
coordinatore per update su canali (topic) che
vengono usati per inviare update a tutti i client
interessati (notifiche push come nelle news/feed)
89899/6/18 9090
9/6/18 9191
9/6/18 9292
9/6/18
MQTT ha 3 livelli di quality of service (QoS)
93939/6/18
Esistono diversi server MQTT pubblici sui quai fare
prove. Ad esempio
http://www.hivemq.com/demos/websocket-client/,
http://test.mosquitto.org/ e plugin di chrome come
mqqtlens
https://chrome.google.com/webstore/detail/mqttlens
/hemojaaeigabkbcookmlgmdigohjobjm
94949/6/18
I nomi delle topic hanno una struttura a directory
come nel caso degli URI’s
95959/6/18
Per le subscription si possono usare wild card che
individuano singoli livelli di un albero (insieme di
pathnames)
96969/6/18
…oppure interi sottoalberi (insiemi di suffissi di
cammini)
97979/6/18 9898
9/6/18
Websocket è un protocollo che combina REST (e
quindi è supportato da browser) con connessioni
TCP per scambiare flussi di dati in real-time
99999/6/18
Dopo una fase iniziale simile al protocollo
REST/HTTP viene aperto un socket TCP attraverso
il quale vengono scambiati dati in maniera
bidirezionale tra client e server
100
1009/6/18
Dopo una fase iniziale simile al protocollo
REST/HTTP viene aperto un socket TCP attraverso
il quale vengono scambiati dati in maniera
bidirezionale tra client e server
101
1019/6/18
Dopo una fase iniziale simile al protocollo
REST/HTTP viene aperto un socket TCP attraverso
il quale vengono scambiati dati in maniera
bidirezionale tra client e server
102
1029/6/18
Dopo una fase iniziale simile al protocollo
REST/HTTP viene aperto un socket TCP attraverso
il quale vengono scambiati dati in maniera
bidirezionale tra client e server
103
1039/6/18
Dopo una fase iniziale simile al protocollo
REST/HTTP viene aperto un socket TCP attraverso
il quale vengono scambiati dati in maniera
bidirezionale tra client e server
104
1049/6/18 105 105
9/6/18
Le piattaforme cloud forniscono servizi su Internet per
storage (come Google Drive) accessibile da ogni
dispositivo in ogni luogo, per rendere scalabili le
applicazioni tramite macchine virtuali, per
connettere dispositivi e applicazioni, per prendere
decisioni in sistemi distribuiti geograficamente
106
1069/6/18
Le piattaforme IoT hanno una struttura simile ad un
sistema operativo distribuito su rete e si
appoggiano al cloud per la gestione dei dati
107
1079/6/18
Alcuni esempi di piattaforme IoT
108
1089/6/18
Il sistema Node.js è n framework per la creazione di
applicazioni IoT basate sul paradigma ad eventi
109
1099/6/18
Esempio di server HTTP in Node.js. Vedremo nella
parte pratica sia Javascript che Node.js oltre ad
esempi di piattaforme IoT e altri strumenti di
sviluppo come Node-red
110
110Puoi anche leggere
