Che materia stai cercando?

Internet of things

Appunti di fondamenti di Internet e reti su Internet of things basati su appunti personali del publisher presi alle lezioni della prof. Grieco dell’università degli Studi del Politecnico di Bari - Poliba, facoltà di Ingegneria I, Corso di laurea in ingegneria gestionale. Scarica il file in formato PDF!

Esame di Fondamenti di internet e reti docente Prof. L. Grieco

Anteprima

ESTRATTO DOCUMENTO

o al server o nell’intermezzo tra client e server. A cosa serve? Ogni volta che faccio

una richiesta chiedendo una risorsa, questa risorsa che io ricevo la mantengo in

memoria, però se dopo 10 secondi dovessi fare un’ulteriore richiesta per velocizzare

le tempistiche di ricezione della risorsa, è necessario che ci sia un’entità che mi faccia

cache. Cioè mi memorizza in maniera temporanea la risorsa che io ho richiesto un

attimo prima. Successivamente studieremo le problematiche relative alla memoria

cache: supponiamo che io stia chiedendo una risorsa A, questa risorsa A viene messa

in una cache e un utente cerca in qualche modo di modificare il contenuto della

risorsa che è presente in cache in modo tale che, quando l’altro utente richiede la

stessa risorsa, invece di ricevere quella che aveva chiesto in precedenza ne riceve una

modificata. Questo problema viene affrontato con meccanismi di sicurezza. Ad

esempio firmando il dato inserito nella cache. Questo schema architetturale usa

principalmente il protocollo http sia per fare richieste di dati, sia per leggere dati, sia

per cancellare dati racchiudibili in un acronimo: CRUD (CREATE READ UPDATE

DELETE).

REST quindi non è un protocollo, ma bensì uno stile architetturale. Perché è

particolare uno “stile architetturale”? Nell’ambito dell’ingegneria del software,

quando lavoro su un software in generale posso decidere di utilizzare un pattern, cioè,

utilizzare un modello con il quale andare a creare le componenti. Per dire a questi

componenti come devono comunicare tra di loro, non bisogna dare per scontato che

quando si usa un programma esista un solo modulo, ma utilizza tanti moduli

all’interno del programma, il fatto che si parli di stile architetturale è proprio per il

fatto che l’architettura, cioè il modo con cui vengono scambiati i messaggi deve

avvenire secondo un certo canone. In questo caso REST è uno stile architetturale

perché all’interno di questo stile io vado a definire che la comunicazione deve essere

di tipo stateless e quindi che non deve esserci memoria, e deve essere composta da

client e server, quindi le caratteristiche di questo stile architetturale vanno in qualche

modo esplicitate perché definiscono lo schema.

Perché non possiamo effettivamente utilizzare sempre l’http all’interno dell’IoT?

Dispositivo telos revisione A, revisione B e in base alle revisioni si chiama telosA o

telosB. La caratteristica di questo dispositivo è che c’è un unico controllore a 16 bit.

Arduino invece utilizza un controllore a 8 bit quindi le capacità computazionali di

questi dispositivi sono nettamente aumentate.

Provate a fare un confronto tra un pc che avete a casa e questo dispositivo. Ci sarà un

abisso di differenza in termini di RAM, storage e anche in termini di velocità per cui

il protocollo http quando è nato, non è nato per poter rispondere a queste

caratteristiche ma per poter rispondere a caratteristiche differenti. Utilizzare il

protocollo http su questi dispositivi significherebbe in qualche modo andare a

consumare sia capacità di memoria ma anche capacità prestazionali per cui diciamo

che non è possibile utilizzare il protocollo http, bisogna trovare un’alternativa. Anche

il protocollo TLS è pesate per questo tipo di dispositivi bisogna quindi usare il

protocollo DTLS che si occuperà di andare a comprimere la rete di quel protocollo

per cercare di ridurre l’effort. Anche il protocollo DCB non lo posso utilizzare perché

la differenza tra il protocollo DCB e il protocollo DB è che il DCB utilizza un

meccanismo per rendere in qualche modo la comunicazione affidabile rispetto al

protocollo DB (DCB: meccanismi di controllo, trasmissione, controllo). Quando

guardiamo le serie tv, lo streaming real time viene fatto utilizzando il protocollo DB

perché anche se si dovesse perdere un dato non è importante. Un DB non fa sempre

controlli, a differenza del DCB. SSL è stato sostituito da TLS per garantire la

sicurezza tra client e server. TLS è un protocollo pesante. Se voglio garantire che il

dato sia sicuro devo cercare di trovare un altro protocollo che si adatti a questo

dispositivo. Ecco perché nasce il COAP (Constrained Application Protocol). CoAP

è un protocollo al livello applicativo che nasce per ambienti vincolanti, cioè abbiamo

delle peculiarità a livello sia prestazionale che computazionale. Il protocollo COAP è

stato progettato da IETF Internet Engineering Task Force e CORe Constrained

RESTful Environments. Nato per garantire l’interoperabilità con il mondo del web

cioè il mondo con il quale abbiamo a che fare tutti i giorni. 4 anni fa il protocollo

CoAP non era stato standardizzato, quindi si stava cercando di capire come

strutturarlo cioè come garantire che un messaggio, piuttosto che un altro, potrebbe

avere senso o no e le caratteristiche da garantire. Dopo anni di lavoro su questo

protocollo è stato rilasciato lo standard ufficiale che è RFC 7252. Documento che mi

scrive tutte le caratteristiche di questo protocollo. Questo protocollo viene sostituito

al protocollo http. Cioè è identico all’http solo che questo posso utilizzarlo in

ambienti costrained. Caratteristiche:

 Document – Centric: quando ricevo un dato, questo dato è contestualizzato,

parliamo di un’informazione.

Esempio: se chiedo la temperatura da un sensore, non ricevo solo 23,5 gradi

ma ricevo un messaggio simile ad un documento con una struttura

 Request/Response mode, risorsa- risposta, chiedo una risorsa ricevo una

risposta, OBSERVE FLAG che serve a rimanere aggiornato. Supponiamo che

faccio una richiesta, ad esempio aggiornamento temperatura. Questo valore

viene comunicato ogni minuto, se non voglio stare li ad inviare le richieste

ogni minuto ma voglio questo dato automaticamente posso specificare

nell’observe flag un valore ad esempio 1, per aggiornare automaticamente

dopo la prima richiesta.

 Binding, su quale porta posso comunicare? (http utilizza la porta 80), CoAP

oltre ad utilizzare un protocollo DB, non utilizza la stessa porta dell’http, ma la

5683. Https è invece http che utilizza un TLS per garantire la sicurezza durante

la trasmissione dei dati, viene associata la porta 443, perché è uno standard.

 Asincronus Messages Exchange, i messaggi di richiesta di risposta

avvengono in maniera asincrona, cioè se chiedo un’informazione e questa info

non me la date subito, non è un problema perché rimango in attesa, non è

necessario essere connessi l’uno con l’altro, posso anche essere offline dopo

aver mandato la richiesta di

informazione e poi ottengo la risposta anche quando sono offline, quando mi

ricollego riceverò il messaggio (esempio: chat).

 Low Header Overhead, ha un eder che rispetto all’eder di http è molto più

efficiente, cioè meno grande. Trasporto sul canale di distribuzione meno dati.

 Parsing Complexity: cioè quando ricevo un messaggio, formato da diversi

campi chi sta dall’altra parte deve fare un’oprazione di parsing. PARSING:

sintassi utilizzata che serve per estrarre tutti i campi singolarmente dal

messaggio.

 Simple proxying and Caching Capabilities

 Security binding to DTLS, DTLS ha un vantaggio rispetto a TLS perché

utilizza il protocollo UDB, nonché un protocollo che diversamente dal

protocollo DCB, non richiede meccanismi per quanto concerne il controllo

della trasmissione, o un riscontro, quindi è un protocollo più leggero, dovuto al

fatto che sto utilizzando DB, perché è un DB in qualche modo che dice di

essere più semplice a causa del fatto che non deve garantire l’affidabilità. Per

cui la sicurezza è una sicurezza molto più leggera.

Un altro protocollo per garantire la sicurezza del CoAP è l’OSCOAP.

Apache garantisce un servizio su una porta definita. Apache HTTP Server, o più

comunemente Apache, è il nome di un server web libero sviluppato dalla Apache

Software Foundation. È la piattaforma server Web modulare più diffusa, in grado di

operare su una grande varietà di sistemi operativi. Apache è un software che realizza

le funzioni di trasporto delle informazioni, di internetwork e di collegamento, ed ha il

vantaggio di offrire funzioni di controllo per la sicurezza come quelle effettuate da un

proxy.

Range di porte: I numeri delle porte registrate sono quelli nell'intervallo 1024-

49151. I numeri di porta dell'intervallo 49152-65535 appartengono a porte private o

dinamiche e non sono utilizzati da una applicazione in particolare. (35.33)

Cerchiamo il paradigma che viene utilizzato all’interno di questo protocollo è “Client

Server”: “Client 1”, “Client 2” e “Client 3”; faccio una richiesta al server, ricevo una

risposta. Anche questo, fa una richiesta al server e riceve una risposta. Cosa richiede?

Probabilmente sta richiedendo sicuramente una risorsa. È chiaro che, in realtà non è

proprio così, però è chiaro che ogni richiesta e ogni risposta che io faccio contiene

comunque un codice. “Response code”, ha un significato un po’ più particolare, cioè

che significa? Facciamo un esempio pratico per capire: quando io sto visitando un

sito, vi è mai capitato di vedere “404 – Not Found”?!?! Quello è un codice di

risposta. 404 è un codice di risposta. Significa appunto che la risorsa non è stata

trovata. Oppure 205: la risorsa è stata trovata. Oppure 403 “forbidden” cioè l’accesso

a quella risorsa è proibito, e non posso farlo. E quindi, alla stessa identica maniera di

come fa il protocollo http, lo fa anche il protocollo CoAP.

Vediamo, che significa Coap Two Layer Approach: il discorso di dire CoAP Two

Layer Approach è un discorso più logico che fisico: cioè non è vero a livello pratico

questo discorso, questo è un discorso logico che vi serve a capire come funzionano le

interazioni con il protocollo e di fatti lo vediamo.

Sotto, a livello di trasporto abbiamo l’UDP, sopra abbiamo “application” cioè

un’applicazione che state utilizzando voi. Una qualsiasi app. Qui abbiamo il

protocollo CoAP. Allora che cosa dice questo approccio? Dice: guarda, per quanto

riguarda il trasporto dei messaggi, ti devi in qualche modo affidare al protocollo

sottostante, quindi il protocollo UDP. Mentre per quanto riguarda le “requests” e le

“respons” è dato dall’applicativo che io sto utilizzando. Che vuol dire? Vuol dire che

quando io sto utilizzando Facebook, e metto “mi piace” ad una determinata cosa

oppure il fatto che io stia aprendo un link, è una richiesta. Ovviamente se io faccio

una richiesta, mi aspetto comunque di ricevere una risposta. Questa cosa qui vedetela

in qualche modo come se fosse gestita a livello astratto dall’applicazione stessa. È

chiaro che questi metodi di “request-respons” utilizzano i codici che vi ho detto prima

(404-205-403) i codici risposta alla richiesta di una risorsa.

Ora cerchiamo di vedere come è strutturato effettivamente un HEADER del

protocollo CoAP, cosa c’è dentro?

Il primo campo è VER. Che cosa specifica VER? specifica la versione del protocollo

CoAP che in questo caso è 1.

Poi abbiamo questo campo T, che specifica la tipologia del messaggio: questa è una

cosa che vi spiegherò bene nelle slide successive, e vi farò capire cosa significa

“confirmable”, “non confirmable”, ACK e “reset”. Per il momento vi farò capire che

noi possiamo avere 4 tipologie di messaggi. Token: la lunghezza del “Token”, mi

dice quanto è lungo questo campo qui. Il motivo è semplice, perché se io non vado a

specificare la lunghezza di questo campo, io so dove inizia ma non so dove finisce;

allora se io so quanto è lungo quel campo, so che quando arriverò qui, arriverà la fine

della lunghezza del messaggio che devo andare a leggere e so che ho letto questa

parte, servirà quindi in qualche modo per facilitare l’operazione successiva.

Poi abbiamo CODE, quello che vi ho detto prima è il response code. Nel grafico ci

sono i primi 3 byte che rappresentano la classe 0245, mentre gli ultimi 5 sono i

dettagli.

Alla fine ci sono i dettagli del messaggio però queste cose sono molto ma molto più

particolari cioè, in realtà non necessitano di una spiegazione precisa, ma queste si.

Che significa che i primi 3 byte sono la classe 0245? Allora il codice 0 identifica che

io sto facendo una richiesta. Quindi quando il client sta chiedendo una risorsa deve

specificare ad esempio 0 come CODE, quando ho una risposta, la risposta viene

contrassegnata da numero

2. Il 4 invece sta a significare che, il 4 è client error respons.

Allora ve lo dico in inglese: questo che identifica una request; una successful respons,

unaclient error respons e un server error respons. Che significa? Il 4 significa errore

da parte del client, mentre il 5 errore da parte del server.

Poi abbiamo il message ID: è chiaro che voi dovete sapere che ogni messaggio che

mando, è costituito da un ID, cioè da un identificativo: cioè se io ti dico “Ciao”, in

realtà, supponiamo che il nostro identificativo si il tempo, Allora io associo

l’identificativo del tempo al messaggio che ti ho mandato. È chiaro però che se io ho

iniziato la comunicazione questo message ID deve rimanere lo stesso. Io devo sapere

che sto comunicando con te. Se poi dico ciao ad un’altra persona, avrà un altro

message ID. A che serve? Serve anche per poter rilevare duplicati. Perché

probabilmente io posso in qualche modo ritrasmetterti lo stesso messaggio cioè ti

posso dire CIAO la prima volta e CIAO la seconda, però è chiaro che dall’altra parte

devo capire se sto ricevendo 2 volte lo stesso messaggio, quindi devo cercare in

qualche modo di rilevare i duplicati.

Poi abbiamo l’utilizzo del TOKEN che serve ad andare a correlare le richieste e le

risposte cioè in qualche modo quando io chiedo qualcosa ad esempio una risorsa,

devo in qualche modo associare a questa richiesta un TOKEN cioè un oggetto che in

qualche modo mi permette di identificare la comunicazione che io sto avendo con

un’altra entità. Poi abbiamo il PAYLOAD MAKER e il PAYLOAD, contenuto del

messaggio stesso. Esistono diverse tipologie di messaggi, un messaggio di tipo

CONFIRMABLE, un messaggio di tipo NON CONFIRMABLE, ACK e RESET.

 Reset, supponiamo di salutare un cinese che non sa l’italiano, e diciamo al

cinese ‘ciao’, il cinese non capisce e ci manda un reset, cioè ci dice ‘guarda io

non riesco a capirti, non supporto la tua lingua’. Nel protocollo coap si traduce

nel fatto che se io sto mandando un messaggio di questo genere ma dall’altra

parte non è supportato devo fare saper che non supporto determinate cose.

 L’ACK, sta a significare che in seguito ad una richiesta, confermo che tu hai

ricevuto il messaggio.

Ora passiamo ad esaminare queste due tipologie di messaggi:

 Confirmable, che significa? Ho necessità di mandare un messaggio di tipo

confirmable quando voglio un riscontro quindi quando voglio sapere se

dall’altra parte la richiesta che io ho fatto nei confronti del server è stata

ricevuta cioè è necessario che io abbia il riscontro perché magari sto chiedendo

una risorsa in particolare e mi serve sapere se questa richiesta della risposta è

stata pervenuta. UDP garantisce una affidabilità nelle telecomunicazioni? NO.

Allora come faccio in qualche modo a garantirlo a livello applicativo? A livello

applicativo si inserisce un’operazione in più come è possibile vedere:

 Non Confirmable, serve a dire semplicemente che ho bisogno di una

determinata risorsa però non voglio sapere se la richiesta è stata o non è stata

pervenuta, esempio: leggere la temperatura dal sensore, non è di vitale

importanza, ma leggere invece la temperatura di un malato terminale è

importante, mi serve capire. In un contesto domotico potrebbe interessarmi

sono un messaggio NON mentre in un contesto non domotico, come quello

sanitario ho bisogno di mandare un messaggio per il quale mi aspetto una

risposta.

Nella slide 10 inoltre per il confirmable massege c’è: Default Timeout and

Exponential Backoff, dove timeout è un intervallo di tempo in cui vado a definire una

determinata trasmissione nel momento in cui non ricevo la conferma che io ho fatto

quella richiesta. L’algoritmo che permette di definire il numero di tramissioni si

chiama Exponential Backoff, tutto questo chiaramente si riferisce allo stesso ID del

messaggio dell’ACK.

Tutto quello che vi è stato detto, in realtà si puoò riassumere in questi quattro

esempi:

Esempio 1

CON voglio una conferma, specifico l’ID del messaggio, faccio una richiesta GET,

cioè voglio una risorsa, specifico il nome della risorsa che voglio cioè la temperatura,

e specifico anche il TOKEN, che può avere diverse utilità, (esempio “la sessione che

ho instaurato con te deve essere sempre quella, non ne dobbiamo creare un’altra; se io

sto parlando con lui quando inizio la conversazione non è che gli dico ciao, e dopo 10

min gli dico di nuovo ciao bensì riprendo la conversazione, e posso farlo con

TOKEN). Ricevo l’ACK.

Esempio 2

Chiedo la temperatura ma il nodo sul quale ci sono i sensori mi da una risposta di

ERROR

4.04 e dico al client che la risorsa che ha chiesta non c’è: “not found”.

Esempio 3

Faccio una richiesta di tipo NON CONFIRMABLE cioè non voglio l’ACK nella

risposta. Ricevo il contenuto però l’ho solo ricevuto, nella risposta non c’è la

conferma.

Supponiamo che per un motivo faccio la richiesta relativa alla temperature, ma non

ricevo la risposta perché il server non si sente obbligato a rispondere (NON), se

invece come nell’esempio 1 faccio una richiesta (CON) il server è obbligato a

rispondere. Sostanzialmente in questi due casi, quando vai a mandare una richiesta

col CON sto chiedendo una qualità del servizio. Se invece non ti serve la qualità, ti

basta il NON. Col CON pretendi una risposta.

Se io ho già richiesto un dato e ora lo chiedo nuovamente e magari il dato è lo stesso,

quel dato lo posso ricevere direttamente dalla memoria cash invece che contattare il

server e fare la richiesta al server. Vi è inoltre il Resource Discovery, Resource

Discovery significa andare a ricercare delle risorse. Quando invio una richiesta di tipo

multicast ovvero quando faccio una richiesta a tutti i nodi presenti all’interno di una

rete invio ad esempio “GET

./well-known/core ”, questa stringa dice “ forniscimi tutte le risorse che posseggono i

nodi”.

Contatto un nodo che chiamo nodo A cui invio la richiesta GET./well-known/core , il

risultato di questo nodo sono tutte le risorse che questo nodo ha raccolto es. livelloo

della temperatura, livello della luminosità, valore dell’accelerometro. Questo viene

fatto per tutti i nodi che ricevono la richiesta non solo per il nodo A. La risposta che

riceverò sarà una risposta ben strutturata con la quale vengono identificate le risorse

che io ho richiesto.

Cosa vuol dire questa slide? Da un lato ho la rete internet, dall’altro una rete con nodi

a basse capacità computazionali. A sinistra ho un server http e un nodo http. Questi

siamo noi. Faccio una richiesta al server, voglio ricevere una determinata risorsa

(temperatura di un sensore). Se io sono connesso a internet e voglio leggere il valore di

questo nodo non potrò usare il protocollo http perché non si può usare nell’IoT perciò

se in quel punto si parla http mi farò aiutare dal translator che, in questo caso, è il

Proxy. Il proxy in questo ambiente connette due mondi e dice che le richieste che sono

ricevute dal server http devono essere tradotte in richieste CoAP. Diverso è il disegno

sottostante in cui il dialogo tra il server e il client definito all’interno dell’ambiente

funziona già con i protocollo CoAP, ciò serve per garantire l’interoperabilità e far

quindi comunicare anche i due protocolli che sono tra loro molto simili ma che in

realtà sono diversi.

Questa cosa l’ho già spiegata prima. Vi ricordate quando ho detto l’observer impostato

a 1 per rimanere aggiornato sulla risorsa? È questo: abbiamo client e server. Io mi sto

registrando al server dicendo ogni volta che c’è un aggiornamento relativo alla risorsa

che ti sto chiedendo mandami la risposta con l’aggiornamento infatti la prima risposta

è 22.9°C, la seconda 22.8, la terza 23.1 a una determinata distanza di tempo.

supponiamo che un cliente malintenzionato si introduca e vada a modificare il valore

della risorsa e cambi il valore 22.8°C con 60°C per far scattare l’allarme antincendio

ma l’incendio non c’è. Allora ci possono essere dei problemi relativi alla validazione

del contenuto ma queste sono cose che hanno a che fare con gli aspetti di sicurezza

che oggi non vedremo.

Un’alternativa al protocollo CoAP è MQTT (Message Queueing Telemetry Transport).

Questo protocollo utilizza un pattern diverso da client/service ma usa un paradigma di

tipo publish/subscribe. Ciò significa che se io sono colui che deve mettere dei

contenuti in rete sono publisher, coloro che vogliono ricevere i dati sono subscriber. Il

trasporto dei messaggi è payload-agnostic ovvero: non mi interessa il contenuto

all’interno del dato. MQTT utilizza TCP/IP, garantisce tre livelli di Quality of Service:

At Most Once, At Least Once, Exactly Once. L’overhead è basso, il numero dei

messaggi è basso. È poi presente un meccanismo Last Will and Testment che serve per

indicare cosa deve succedere nel caso si verifichi qualche anomalia.

Questa è la rappresentazione grafica: in cui è presente il publisher, l’entità che immette

il contenuto ovvero colui che produce l’informazione, il subscriber ovvero chi vuole

ricevere l’informazione e, infine, il broker che è il mediatore tra i due. Ogni publisher

quando contatta il broker deve specificare un contenitore che si chiama topic e gli dico

cosa andrò a mettere all’interno. Se il subscriber è interessato farà la sottoscrizione a

topic.

ESEMPIO. Se io ho un topic che si chiama tecnologia e il publisher fa il publishing

dei dati all’interno del topic tecnologia, il subscriber che è interessato a ricevere le

notizia relative a tecnologia, effettua la sottoscrizione attraverso il broker al topic

tecnologia.

Cosa c’è di strano qui? Abbiamo detto che il subscriber dovrebbe collegarsi in quale

modo direttamente al broker per ricevere l’informazione però qui non è così perché

questo schema è particolare che sta a significare che questo nodo che è presente tra il

subscriber e il broker sta funzionando come un altro broker.

Anche qui abbiamo un aider perché non posso mandare messaggi se non ho una

struttura con la quale posso farlo. È presente anche una tipologia di messaggio, il

message type.

La prima iterazione clietbroker. Il client è generico, può essere il publisher o il

subscriber e invia un messaggio di tipo “connect” al broker. Il broker riceve la

richiesta e invia la risposta “connack” cioè connect up ho ricevuto la richiesta di

connessione. La parte blu la fa il subscriber il quale ha visto una serie di topic

interessante e invia una richiesta di tipo “subscribe” ad un determinato topic. Il broker

dice ho ricevuto la tua richiesta di subscribe ti invio l’ack “suback”, il publisher invia

anche lui una richiesta al broker “publishing” però qui la cosa è diversa perché colui

che invia l’informazione sul topic può decidere qual è la qualità della comunicazione

che vuole garantire tra lui e l’entità sulla quale sta facendo publish dell’informazione

stessa. Perché questo? Noi abbiamo tre livelli di qualità:

-QoS level 0 ed è il best effort,

-QoS level 1at- least- once delivery,

- QoS level 2 exactly- once delivery.

Se io invio un messaggio di tipo publish mi aspetto di rivecere un messaggio di tipo

puback cioè ho rivecuto la tua richiesta di publish. In base al livello di qualità che

vado a garantire all’interno di una comunicazione, io oltre a mandare il puback posso

anche dire di fare pubrel che non è nient’altro che una conferma del messaggio di

puback così come anche il pubrec e il pubcomp. Tutto varia in base alla qualità del

servizio che voglio garantire.

Il messaggio PUBCOMP significa il publishing della risorsa è stato completato con

successo, il PUBREL significa publishing release, il PUBREC publish received.

Nel momento in cui il client vuole fare l’ UNSUBSCRIBE alla risorsa invierà un

messaggio al broker dicendo unsubscribe. Se ricevo un unsubscribe devo mandare

anche una richiesta dicendo che ho ricevuto questa richiesta e invierò un

UNSUBACK, lo stesso dicasi per il PINGREQ per interrogare, per vedere se c’è

comunicazione e DISCONNECT per chiudere la comunicazione.

Questo è ciò che vi stavo dicendo prima:

QoS Level =0 ----- At Most Once Delivery, questo è come il non del CoAP: invio il

publish ma non ricevo nessuna ack. Invece voglio garantire una qualità della

comunicazione più efficiente allora introduco QoS Level =1 At least once delivery.

Faccio il publish del messaggio e ricevo l’ack per dire ok ho ricevuto la richiesta.

Voglio garantire una comunicazione altamente affidabile, imposto quindi un QoS pari

a 2 dove ci sono tre ack che si chiamano PUBREL PUBREC e PUBCOMP.

PUBCOMP è il messaggio finale e dice che ho ricevuto il messaggio relativo alla

risorsa e tu publisher puoi pubblicare.

Quali sono le altre caratteristiche?

-Last Will and Testment, signaling of abnormal disconnection. Significa che quando

c’è una disconnessione da parte del client questa cosa deve essere gestita. Gestita in

che senso? Se un client si disconnette dal server o viceversa io devo sapere

effettivamente cosa fare quando si verifica questa problematica. Se il nodo dovesse

avere delle problematiche deve esserci un testamento che mi dica cosa devo fare.

ESEMPIO: all’interno di casa ho un nodo che legge il valore della luminosità di una

stanza, magari lascio le luci accese perché ho paura che entrino i ladri. Il nodo legge il

valore della luminosità della stanza sa che me ne dovevo andare su un determinato

topic che ho definito sul broker. Quindi periodicamente, ogni 2 minuti per esempio, mi

manda un messaggio con il valore della luminosità che ha acquisito. Però nel

momento in cui il valore della luminosità non viene più acquisito dal nodo (cioè il

client si disconnette), il server dall’altra parte deve sapere cosa fare e quindi magari

all’interno del server c’è un altro topic che si chiama topic di emergenza che proverà a

mandare un messaggio direttamente a me sul cellulare con un sms dicendo che il tuo

nodo è morto questo è l’ultimo messaggio che io ho ricevuto.

-Retain Flag, serve per dire al topic di salvare i messaggi di un determinato topic in

modo tale che se il nodo per un motivo x dovesse morire, quando si riconnette li riceve

tutti insieme. Se ho io fatto una richiesta perché voglio leggere determinate

informazioni però magari il nodo è morto, con il retain flag vado a memorizzare il

contenuto dei messaggi all’interno del server relativi ad un determinato topic. Quando

io vado a fare la richiesta riceverò tutti insieme i messaggi che sono stati pubblicati su

quel topic.

-Wildcard Characters, guardate qui ( + single-level wildcard * multi-level

wildcard ), c’è il + e * solo che ormai l’asterisco è obsoleto e si utilizza # al posto di

*. Quando io faccio

una richiesta del tipo (scrive qualcosa alla lavagna) questo qui in più è un Wildcard a

singolo livello. Cosa significa? Significa che se dovessi fare una richiesta di questo

genere (scrive qualcosa) questa richiesta è valida o meglio la risposta che io riceverò

prenderà Bari,Trani, Bitonto e altre città presenti qui tra Puglia e temp. Se però

dovessi fare una richiesta del tipo “italia puglia bari japigia temp” questa richiesta non

è più valida perché è a singolo livello quindi quando io andrò a fare una richiesta con

Wildcard lui prenderà le risorse da tutti quelli che iniziano con Italia puglia, qui in

mezzo è un valore che dipende comunque dal contesto può essere Bari Bitonto e poi

abbiamo temp che sta per temperatura. Se invece al posto di temp c’è accelerazione la

richiesta non è soddisfatta perché questa richiesta qua con questo Wildcard in mezzo

mi dice come deve essere fatta una determinata richiesta. Se al posto di questo

simbolo qui avessi avuto il cancelletto significa che il Wildcard è da multilivello e

deve prendere tutto quello che può esserci tra Puglia e temp quindi magari posso

trovare il nome della città di Bari, il portiere, la casa di una persona, fino ad arrivare a

temp. Allora qui è diverso. Il simbolo # significa prendi tutto quello che viene dopo la

scritta Puglia però la parte finale deve finire con temp altrimenti la richiesta non è

valida. Ovviamente questo carattere posso metterlo ovunque.

-Namespace gerarchico, significa che c’è una gerarchia tra Italia, Puglia, Bari. Come

anche qui, abbiamo infatti finance/stock/ibm ma abbiamo anche

finance/stock/ibm/closingPrice e finance/stock/ibm/currentPrice sono in qualche modo

dettagli di rete però al posto di ibm posso anche avere finance/stock/apple. Serve quindi

per far capire il valore di interesse fino ad arrivare all’azienda. Si parte dalla

macrocategoria fino a scendere nel dettaglio.

C’è però un problema nel MQTT. Avete visto i nodi piccolini che vi ho fatto vedere

prima? Quelli sono nodi con cui MQTT non si può usare, il rotocita 2mc4, la

dimensione massima del messaggio che io posso mandare è 127 byte, una fesseria.

Quindi, dato che MQTT ha reinold che ha dimensioni davvero variabili e può arrivare

sino a 24 mega se non anche di più, questa cosa non è efficiente per dispositivi che

devono essere immessi all’interno di un contesto IoT.

Quindi, il primo problema è che la lunghezza del pacchetto è troppo grande, non va

bene per quei dispositivi che io devo utilizzare a livello fisico il rotocita 2mc4. Nasce

quindi MQTT- SN, prima si chiamava solo MQTT-S ma la S era un po’

incomprensibile per alcuni per cui si è chiamato MQTT-SN cioè MQTT for wireless

sensor networks. Questa versione viene utilizzata per quei dispositivi a basso costo

computazionale che non possono permettersi il lusso di usare la batteria come se fosse

un normale pc attaccato alla corrente. Deve essere utilizzato per tutti questi aspetti qui.

Qui abbiamo un modello di funzionamento di questi MQTT e qui due meccanismi di

funzionamento del Gateway. Il Gateway non è altro che l’anello di congiunzione tra il

client e il broker. Questo è il gate esterno, questo è interno.

Ricevo una richiesta e la mando direttamente al broker e poi ho un Forwarder. La

differenza tra il Gateway ed il Forwarder è che il Forwarder quando riceve un pacchetto

deve incapsularlo in un altro frame, inviare questo pacchetto incapsulato e dopo che il

gateway ha ricevuto questo pacchetto deve decapsularlo e inviare il contenuto al broker

come gliel’ha inviato il client. L’utilità di questa cosa sta nel fatto che si possono avere

delle esigenze particolari durante la trasmissione del messaggio.

Cerchiamo di capire ora la funzionalità del Gateway tra questa e questa. Comunque

come potete vedere qui la richiesta è di tipo MQTT quindi il Gateway si occupa di

tradurre la richiesta da parte di MQTT-SN in MQTT al broker. Guardiamo le tipologie

di Gateway cosa cambia dal transparent al aggregate. Nel trasparent c’è solo una

traduzione da MQTT-SN a MQTT infatti ad ogni client c’è una connessione con il

broker. Quindi per n-client che si connettono al gateway io ho n-connessioni del

Gateway con il broker. Qui invece ho n- client, un gateway e un broker. Per n-client,

tutte le richieste vengono aggregate in una sola richiesta che verrà fatta poi al broker.

Qual è quindi la differenza tra i due? Innanzitutto la complessità: il fatto di creare un

aggregate gateway è più complesso perché questo deve avere dei meccanismi che mi

permettono di aggregare tutte le richieste ricevute però è molto più efficiente in termini

di numeri di connessioni perché io posso avere anche 10000 client ma solo una

richiesta sarà fatta dal Gateway al broker.

Qui viene fatto un confronto tra MQTT e MQTT-SN, sono più o meno le stesse cose

che vi ho detto prima. La cosa più importante è che il primo messaggio di connect da

client a server viene suddiviso in tre parti: will-topic e will-message. La parte di topic

non conterrà più il nome ma conterrà un ID perché magari il nome può essere più

dispendioso in termini di byte rispetto ad un ID. Inoltre come possiamo vedere dalle

caratteristiche che vengono messe a confronto MQTT ha una comunicazione point to

point cioè da punto a punto affidabile, con MQTT-SN non è affidabile perché io uso

nonIP a livello di trasporto. Nel campo del networking MQTT lo posso usare con wi-fi

o 3G, MQTT-SN posso utilizzarlo anche con tecnologie bluetooth, RFD... la

dimensione massima del messaggio è 24 mega per MQTT e 128 byte per MQTT-SN.

Inoltre MQTT-SN è ottimizzato per un discorso di consumo, supporta lo sleeping

clients che è una funzionalità per cui i messaggi che io invio ad un determinato client

vengono conservati in un buffer di memoria quando il client sta dormendo ovvero non

è connesso quindi è prevista una memoria in cui vado a salvare questi messaggi che

vengono in qualche modo inviati, quando il client si risveglia allora questi messaggi

saranno inviati in qualche modo tutti insieme. Inoltre è garantito un altro quality of

service che è addirittura di livello -1 ovvero non affidabile cioè mi mandi la richiesta

se la ricevo ok se non la ricevo pazienza. Come faccio a fare interagire MQTT con

MQTT- SN? O utilizzo il forwarder o il gateway. Qui, wireless SA sta per wireless

sensors and acquators cioè sensori ed attuatori. I sensori si occupano di acquisire dati,

l’attuatore è quel dispositivo che dato in input un determinato dato agisce di

conseguenza. Qui sto facendo vedere come far interagire una wireless SA network che

utilizza un MQTT-SN e una LAN convenzionale che viene fatta con i nostri computer.

Come posso farli comunicare? Devo avere qualcuno di mezzo. Non andremo mai a

interrogare da un punto di vista logico il nodo in sé per sé. Se io sto usano MQTT-SN

non posso interrogare direttamente un client MQTT deve esserci sempre un

meccanismo che traduce le richieste per il protocollo di destinazione e viceversa. La

comunicazione è bidirezionale. Abbiamo un ente di standardizzazione del MQTT che

dice quali sono le problematiche presenti all’interno di MQTT, ad esempio

bisognerebbe cercare di specificare la priorità del messaggio, i meccanismi di richiesta

e risposta, una scannerizzazione della subscription perché attualmente non esiste.

Ci sono poi comunque delle altre feature sulle quali bisognerebbe ragionare che

sono addirittura out of scope. L’ultima è che non è garantito alcun meccanismo

di sicurezza perché si presume che utilizzi TLS come fa http. Abbiamo diversi

client e diversi broker, è chiaro che come client abbiamo WebSphere MQ,

Eclipse Pah. Per il server implementation abbiamo Mosquitto, RSMB, e altri

ancora. I progetti sono anche molto interessanti. Ad esermpio vi è “Say It, Sign

It” (SiSi) che aiuta le persone affette da sordità a convertire ciò che loro dicono

con il labiale nella lingua dei segni e questi segnali vengono mandati utilizzando

il protocollo MQTT. MQTT è anche utilizzato nell’ambito delle smartcity per

acquisire serie di dati relative alla luminosità, alla temperatura, al traffico. Può

essere anche usato nell’ambito medico: vi è il paziente a casa, c’è un

monitoraggio del macchinario che acquisisce i dati del paziente, questi dati

vengono mandati tramite internet al message server che li acquisisce e vengono

mandati al sistema di applicazione intelligente che analizzerà i dati e chi sta

dall’altra parte otterrà i dati in maniera di input e potrà verificare le condizioni

del paziente. Le differenze ve le ho già dette,quella che non vi ho detto

probabilmente è questa. Sapete cosa è il NAT all’interno di una rete? Quando voi

vi connettete a internet uscite tutti con un meccanismo ip, supponiamo di avere

una rete e dieci pc collegati, uscirà un solo indirizzo. Con MQTT il problema

non c’è mentre c’è con CoAP ed è necessario fare una specie di tallening o

forwarded per consentire il CoAP in un ambiente in cui tutte le macchine

all’esterno escono con un indirizzo solo. In questa slide vengono definite quali

sono le performance tra MQTT e CoAP, CoAP è un protocollo che sembra essere

più performante ma questo dipende dal QoS che voglio garantire. Questi grafici

fanno vedere:

il tempo che intercorre tra una richiesta e la ricezione del messaggio, e qui

invece fa vedere in quanto tempo riesco a trasferire un determinato numero di

byte.

The IOT WAR: è chiaro che voi pensate che ci sono una marea di protocolli che

vengono definiti nell’ambito del IoT, non solo CoAP o MQTT, ce ne sono anche

altri il cui obiettivo è sempre quello di offrire una messaggistica istantanea solo

che sono protocolli che utilizzano degli approcci differenti. Quindi vi è una

guerra tra questi perché: io devo capire come far comunicare un dispositivo con

un altro, devo fare capire come far comunicare il dispositivo con il server e il

server con il server. Per ogni tipologia di comunicazione devo usare il

protocollo più adatto al contesto. Quello che vedete qui 0,1 millisecondi, 10

millisecondi, 100 millisecondi sono le latenze relative alla comunicazione tra

dispositivo- dispositivo, dispositivo- server e server-server.

Il protocollo AMQP si occupa anche questo della trasmissione dei messaggi, il

protocollo XMPP nasce da un protocollo vecchio che si utilizzava in una chat

chiamata jabber. Le caratteristiche che questi due protocolli offrono sono degli

aspetti di security che hanno, sono versioni diverse di CoAP che hanno però lo

stesso obiettivo: offrire un servizio di messaggistica istantanea. Qual è il

protocollo migliore da usare in IoT? Dipende! Dipende dal contesto, dalla QoS,

dai dispositivi con cui devo interagire, perché ogni protocollo ha pregi e difetti e

occorre scegliere quello più efficiente per quel contesto.

Oggi introduciamo un nuovo argomento parlando di nuovi paradigmi di

comunicazione che fanno parte del future internet. Nel corso del tempo ci si

è resi conto che il modello TCP/IP può essere migliorato per adattarsi ai

nuovi modi di comunicare tramite internet.

Gli argomenti affrontati in questo capitolo fanno parte di topic di ricerca.

All’inizio potranno sembrare un po' inusuali in quanto siamo abituati a ragionare

in termini in indirizzo IP. Quello che presentiamo oggi saranno le linee guida per

le future architetture.

Innanzitutto vedremo cosa vuol dire ICN.

Analizzeremo vari esempi di architetture per poi approfondire l’architettura

Datanet Working; tra i vari progetti rilasciati negli anni, cominceremo vedendo

quello su cui si sta lavorando in maniera più seria. Nella prossima lezione

vedremo anche quali sono i problemi di questa architettura.

Nel corso degli anni ci sono sempre più dispostivi connessi ad internet, sempre

meno costosi, facilmente accessibili e in grado di comunicare con altri

dispositivi presenti in rete. Questo non era previsto inizialmente in quanto

all’inizio, quando il protocollo TCP/IP è stato concepito, avevamo poche

macchine che condividevano poche risorse, quindi la maniera più semplice per

far comunicare i dispositivi era quello di stabilire una connessione punto a punto

(cioè 2 host che volevano scambiarsi i dati eseguono una connessione punto a

punto senza preoccuparsi della struttura sottostante). Man mano che questi dati

sono diventati sempre più accessibili e sono cambiati (prima erano

principalmente testo, ora sono video, immagini, musica, dati di sensori, dati che

cominciano assumere un proprio significato) è emersa la necessità di sapere

quali dati stiamo scambiando per ottimizzarne la connessione.

ES: durante uno streaming ci sono diversi utenti che voglio scaricare il video

contemporaneamente e potrebbero anche essere vicini  potrei cambiare il

modo di comunicare stabilendo una connessione punto a punto tra gli utenti

(=host) stessi.

Quindi la comunicazione è punto-punto: se voglio richiedere un dato devo

stabilire una connessione con il server (questo meccanismo è parzialmente

nascosto dai DNS che ci permettono di raggiungere un server senza inserire

l’indirizzo, ma una serie di parole ES: www.facebook.it).

Oggi cos’è più importante di dove

Quello di cui abbiamo bisogno oggi è di sapere cosa vogliamo piuttosto che

dove risiede anche perché questo dato potrebbe risiedere ovunque ed essere

replicato in vari punti della rete; non è detto che il server a cui effettuo l’accesso

sia il migliore o il più vicino, potrei anche pensare di richiedere lo stesso dato

contemporaneamente a tutti gli host/nodi/entità che hanno quel dato a

disposizione; potrei dividere il file in più sotto pacchetti, chiedere

contemporaneamente a più host diversi e riassemblarli a livello locale. Questo

processo di riassemblaggio è operato oggi dagli CDN (=reti di calcolatori che

hanno un numero elevato di risorse; solitamente ci sono grandi aziende, come

Akamai, che distribuiscono i contenuti per tutti i big come amazon, youtube,…

oppure anche reti peer-to-peer); ovviamente sebbene queste reti implementino

meccanismi per rendere disponibili all’utente le risorse il più vicino possibile,

stiamo parlando di soluzioni sempre a livello applicativo al di sotto delle quali

c’è sempre il protocollo IP (quindi ci sono meccanismi sofisticati per l’ispezione

dei pacchetti, infatti ciò che manca all’indirizzo IP è la conoscenza del tipo di

file che stiamo trasmettendo). Questa comincia ad essere una limitazione.

Un altro degli aspetti su cui IP non fornisce molto supporto è la mobilità:

esistono tecniche come il mobile IP in cui nel momento in cui il nodo mobile

effettua un cambio di rete (=cambia IP), viene utilizzato il “triangolo acuting”

ovvero abbiamo un nodo fisso detto homemagent il quale tiene traccia della

posizione del nodo effettuando una connessione detta tanneling che ha necessità

di indicare costantemente il proprio indirizzo IP quando si sposta per poi

effettuare un routing opportuno verso l’host che sta richiedendo il dato; questa

tecnica funziona, ma è complessa da gestire, soprattutto se pensiamo ad uno

scenario in cui c’è molta mobilità (ES: nel caso dei veicolo).

Altri aspetti che si possono rinnovare sono multicast (poter condividere un

contenuto con più utenti contemporaneamente) e multipath (richiedere lo stesso

dato in sottopacchetti, come detto prima): sono gestiti dal protocollo ip ma

possono essere migliorati.

Ultimo aspetto è la sicurezza: la sicurezza oggi è gestita host to host. Quando si

stabilisce una connessione tra 2 host si cerca di creare un canale sicuro tra gli host

che stanno comunicando, ma ancora una volta quello che andiamo a rafforzare è

l’host, ma no il contenuto in se per se (anche se è cifrato, quindi inaccessibile o

comunque non visibile ad occhio nudo).

Il paradigma ICN si propone proprio perché c’è la necessità di standardizzare

l’approccio per scalare la distribuzione attorno differenti reti che cooperano e

servizi che nativamente soddisfano i requisiti di mobilità e sicurezza. Con questa

tecnologia non avremo più bisogno di conoscere l’indirizzo IP e la posizione

nella rete, ma basterà il suo nome.

ICN: COSA SIGNIFICA?

L’ICN si propone di sviluppare alcuni concetti alternativi per risolvere queste

problematiche; il concetto fondamentale è che il dato è messo al centro della

comunicazione e a livello di rete identifico il dato a livello univoco in quanto è

un dato (e no in base all’ubicazione fisica)  per richiedere un dato nella rete

non avrò più bisogno di indirizzo IP o posizione nel mondo, ma

semplicemente il suo nome.

COME FUNZIONA UN’ARCHITETTURA ICN?

Il modello su larga scala fa riferimento ad un modello di comunicazione

Publish- Subscribe: abbiamo alcuni nodi detti producer che generano i nostri

dati assegnandogli un nome univoco e annunciano la loro disponibilità nella

rete (anche il protocollo IP può utilizzare un modello di comunicazione publish-

subscribe, ma nel protocollo IP per publishing si intende l’invio del dato nella

rete, mentre nell’ICN pubblicare=annunciare, senza inviare, la disponibilità del

dato senza inviarlo)

I subscriber richiedono il contenuto (a differenza del modello tradizionale

publish- subscribe utilizzato nel protocollo IP, qui non posso chiedere dati

non ancora disponibili, mentre lì si).

Il dato richiesto dall’utente viene effettuato il forewording della richiesta

dell’utente in modalità host by host: i router ICN potrebbero rendere loro stessi

disponibile il dato, mentre i router ip non effettuano lo storage dei dati, non

hanno memoria dei contenuti, poichè potrebbe essere un’operazione inutile in

quanto potrebbero non comprendere la cosa che stanno memorizzando; in questo

caso invece potrei effettuare un caching opportunistico: scegliere quali dati

memorizzare e dove.

Il dato potrebbe essermi reso disponibile da qualunque nodo, se nessuno ce l’ha si

chiede al producer direttamente.

Una volta reso disponibile il dato ritorna al subriber e anche in questo caso il

cache può tornarmi utile per eventuali richieste future dello stesso dato (qui però

c’è una differenza di cache in quanto parliamo di Innetwork cache webcache, è

il server che effettua cache dei contenuti a livello locale).

Le differenze rispetto alle architetture rilasciate negli anni sono 3:

 Gestione dei nomi dei contenuti del namespace: come vengono

rappresentati i nomi, quale significato il nome assume.

 Corrispondenza architettura e algoritmi

 Abbiamo varie tecniche di routing: sempre a livello locale, perché la

problematica principale è conoscere il prossimo verso cui indirizzare il

pacchetto, ci sono varie modalità (ES: ci sono nodi che tengono traccia

di quali entità rendono disponibili le informazioni)

Caratteristiche

 I contenuti possono essere richiamati contemporaneamente da diveri

nodi: multipath nativo

 Se un subscriber si sposta può semplicemente richiedere nuovamente la

sottoscrizione  Mobilità seamless (In questo caso è possibile gestire la

mobilità seamless: se esprimo una preferenza per un dato e mi sposto

nella rete, il dato arriverà nel punto in cui stavo prima; quindi lo devo

richiedere; però essendo stato memorizzato nelle cache intermedie, mi

arriverà comunque prima)

 Tutti i contenuti sono resi disponibili usando la stessa

architettura: standardizzazione della distribuzione dei

contenuti

 Alto livello di sicurezza dei contenuti: oltre a verificare l’autenticità di

chi produce il dato, posso verificare anche l’autenticità del dato stesso

semplicemente verificando questa informazione all’interno del pacchetto

in cui mi viene restituito il pacchetto

 Uso più efficiente della capacità del network (grazie al network caching)

Struttura del name space

 Una struttura di tipo gerarchico (può essere vista come molto simile

ad un URL: ci sono vari campi separati da uno /):

Una struttura di questo tipo permette di fare aggregazione:

o posso prevedere una struttura dei contenuti di tipo ad albero

Un’altra operazione che posso effettuare tramite i nomi gerarchici

o sono i controlli di sicurezza, sono controlli di tipo ad albero:

partendo dall’ultimo livello dei componenti che fanno parte del

nome posso verificare dal basso verso l’alto che i vari componenti

siano stati rilasciati a loro volta da entità certificate fino ad arrivare

al provider principale

Non è richiesta la risoluzione aggiuntiva del nome

o L’unicità globale non è garantita

o

 Altre implementazioni sono quelli dei dati Flat:

Non abbiamo un eventuale struttura ad albero= non possiamo

o raggruppare più contenuti sotto uno stesso prefisso non posso

fare riferimento ad un altro contenuto semplicemente

aggiungendo un altro campo

Unicità dei contenuti

o Contenuti autocertificati (dal nome stesso posso verifuicare

o l’autenticità di chi mi ha prodotto il dato)

Partono dall’URL

o E’ richiesta la risoluzione aggiuntiva del nome

o

Altra aspetto che differenzia questo protocollo dagli altri è la gestione del

routing. Altre implementazioni utilizzano la risoluzione dei nomi, ovvero ci sono

meccanismi aggiuntivi e altri nodi con funzionalità dedicate che si occupano di

mappare e rilevare i locators ovvero dov’è consigliabile effettuare il forwarding

per raggiungere il dato effettivo. Altre implementazioni utilizzano invece il nome

per effettuare il forwarding.

DONA

Una delle prime implementazione viste dell’ICN è

DONA: Caratteristiche:

 Uso di flat names:

garantisce che il nome associato al dato resti invariato,

o anche se l’informazione si sposta o cambia il contenuto

 Facilità nella gestione dei contenuti

 il nome è auto-certificato: gli utenti possono verificare che il

contenuto richiesto sia quello effettivamente ricevuto

Vengono utilizzati più Resource Handlers (RH): i RHs sono

o connessi per formare un servizio di name resolution gerarchico

(in questo caso gerarchico sta nel fatto di avere diversi gruppi

RH i quali effettuano la risoluzione dei nomi gerarchici)

Anche qui:

o  I publisher registrano i contenuti

 I subscriber richiedono i contenuti

 La cache viene eseguita a livello di RH

 Problemi:

A livello di routing DONA potrebbe far uso ancora di un routing

o di tipo IP

DONA funziona come un’architettura di tipo overlay: le

o funzionalità non sono implementate a livello di rete

ESEMPIO DI ARCHITETTURA DI DONA

Qui abbiamo un esempio di architettura DONA; ci sono diversi authonomos

systems (AS), ognuno dei quali ha un RS; i diversi RS fanno capo ad un RS che

svolge il ruolo di RS principale e i vari router sono usati per il delivery del dato.

Il publisher annuncia disponibilità del contenuto attraverso un messaggio di tipo

register. Il RS di riferimento dissemina questa in formazione agli RS vicini

(incluso quello di livello superiore). Il subscriber invia al RS più vicino una

richiesta di tipo find e i RS si coordinano tra loro per effettuare il discovery per

trovare il nodo che potrebbe rendere disponibile il dato. A questo punto, definita

la rotta secondo cui il dato può essere reso disponibile, i router dei vari

autonomos systems si occupano di smistare il dato al subscriber. In questo caso il

routing potrebbe essere effettuato avendo informazioni relative agli authonomos

systems che il messaggio di tipo find ha attraversato per richiedere il dato. Nel

caso in cui questa informazione non dovrebbe essere disponibile si fa riferimento

al classico IP.

La struttura dei nodi è costituita da 2 parti (P e L)

 P: è costituita dall’hash della chiave pubblica dell’owner (=principale,

cioè il proprietario, cioè colui che a messo a disposizione il dato)

 L: identificativo associato alla porzione di dato che stiamo richiedendo.

In questo caso per esempio utilizzando algoritmi di tipo asimmetrici, una

volta ricevuto il dato, posso effettuare operazioni simili, come ricalcolare

l’hash della chiave pubblica e vedere se quella del dato ricevuto

corrisponde con quella che ho ricevuto.

Un’altra delle architetture proposte è Pursuit. È una struttura molto simile a

quella vista per DONA ma in questo caso il modello di riferimento è proprio il

Publish Subscribe perché abbiamo una serie di nodi per ogni atonomous system

chiamati Rendezvous Node, ognuno dei quali mappa i router sottostanti per ogni

atonomous system attraverso le Ash table distribuite.

Le Ash table funzionano così: si hanno delle strutture di tipo vettoriali

attraverso le quali possiamo mappare una grande quantità di contenuti in un

dominio ristretto.

Questo è possibile grazie all’inserimento di un contenuto specifico all’interno

della nostra table facendo riferimento all’ash del contenuto (cioè viene

effettuato l’ash del contenuto e inserito nella tabella). In questo modo ad ogni

contenuto viene associate una chiave di accesso all’interno della tabella in

maniera univoca perché appunto identificata dal proprio ash. Questo,

ovviamente, permette un accesso diretto alla risorsa e oltretutto settando le

proprietà delle funzioni di ash possiamo mappare grandi contenuti di dominio

ristretto.

A loro volta queste tabelle d iash vengono distribuite mediante tutti i nodi

ovvero ogni rendez vous node gestisce un certo numero di chiavi della tabella

distribuita e sa esattamente quali nodi si possono raggiungere attraverso se

stesso.

Anche qui la comunicazione è molto simile a quella vista per DONA: avviene la

comunicazione tra consumer e producer con i rispettivi rendez vous node.

Una delle differenze, in questo caso è che ogni volta stabilito dove il dato può

essere reso effettivamente disponibile, abbiamo un nodo aggiuntivo che è il

topology manager che si occupa di mappare il percorso che il dato deve fare

verso il producer.

In questo caso abbiamo la gestione dei nomi a due campi, di cui il primo campo

viene chiamato lo scope ID che serve per fare aggregazioni di tipo gerarchica

anche perché per le operazioni di publish e subscribe può essere effettuato il

machting semplicemente andando a guardare lo scope id di riferimento.

In questo caso il nodo che gestisce la risoluzioni dei nodi è chiamato

NRS , che interagisce con il nodo RS di riferimento.

Il nodo sorgente annuncia la disponibilità del dato e delle rotte attraverso un

protocollo specifico di routing e si hanno due opzioni per richiedere la

disponibilità: o contattando il nodo NRS oppure si può inviare un messaggio di

tipo get, all’interno del quale potrebbe esserci l’informazione dei router

eventualmente da attraversare per arrivare al dato.

Gli scenari di riferimento sono molteplici e quelli per la quale si sta effettuando

maggiore sperimentazione sono essenzialmente video e audio streaming, social

networking e soprattutto mobile e comunicazione tra veicoli proprio perché, in

maniera intrinseca i nodi sono in continua mobilità e in questo caso può risultare

difficile identificare il nodo attraverso il proprio indirizzo ip perché questo

indirizzo ip può cambiare con frequenze molto elevate.

Nell’IOT, le tecnologie di tipo icn possono essere utilizzate come

tecnologie implementate parzialmente a livello applicativo e a livello di

rete parzialmente a supporto di diverse tipologie di protocolli per l’iot.

NAMED DATA NETWORKING (NDN):

Il progetto è partitolo attorno al 2010 al quale

collaborano circa 12 università da ogni parte

del mondo e si può ritenere in qualche modo

che sia una delle applicazioni più complete

del paradigma di CHAIN.

Il focus di NDN (Named Data Networking) è

di richiedere e ottenere dei dati e in un certo

senso il concetto di nodo, di entità viene in un certo senso astratto. Ritroveremo

molte caratteristiche viste in precedenza.

La comunicazione è abilitata secondo due tipologie di pacchetti:

1. INTEREST= attraverso interest si richiede il contenuto, ricevuto

l’interest, il dato, se reso disponibile, è incapsulato in un pacchetto di tipo

date e rispedito al mittente. I nodi sono di tipo gerarchici in un formato

“human readable” con campi separati dallo slash solitamente e facilmente

aggirabili. La caratteristica attraverso cui il percorso secondo il quale il

dato deve essere ritornato al mittente viene effettuato attraverso l’interest

stesso. Questo significa che quando l’interest attraversa un certo numero

di nodi per arrivare al nodo che rende disponibile il dato lascia delle

tracce cosiddetti “breadcrumbs” nei nodi che ha attraversato durante il

percorso. Questo percorso, creato ovviamente sempre in modalità hop by

hop, verrà utilizzato come percorso in maniera inversa per restituire il

dato al consumer.

Ogni nodo nella rete NDN che sia router, consumer o producer mantiene

in memoria 3 strutture principali:

 Content Store (CS), la cache dei contenuti che può

eventualmente rendere disponibili

 Pending Interest Table (PIT) che è una struttura che si occupa di

mappare quali sono gli interest ricevuti dal nodo e le interfacce di

ingresso da cui l’interest è stato ricevuto. Questa struttura

permette di effettuare aggregazione poiché, intanto che l’interest

sta viaggiando nella rete e il dato non è ancora stato ricevuto, la

rispettiva entry all’interno di questa tabella verrà memorizzata.

Intanto che il dato deve essere ancora ricevuto e il tutto viene

anche controllato tramite un time out, intanto che questa entry è

attiva nella tabella e uno stesso interest viene nuovamente

ricevuto per lo stesso dato da un altro nodo, esso non verrà inviato

nella rete ma semplicemente verrà aggiunto un nuovo valore alla

entry che corrisponde al nome del contenuto specificato

nell’interest e interfaccia di arrivo. Se lo stesso interest arriva da

più interfacce, posso pensare di richiedere il dato una sola volta e

di restituirlo una volta arrivato a tutti i consumer interessati a quel

dato

 Forwarding Information Base (FIB) è una struttura che gestisce il

forwarding. Molto simile a quella presente in IP che effettua anche

le stesse operazioni: è a conoscenza di quali sono le interfacce di

uscita verso cui verosimilmente un certo nome è disponibile.

Anche in questo caso per un dato contenuto possiamo

eventualmente avere più interface verso cui è disponibile. Quando

parliamo di interfacce non stiamo parlando di indirizzi ip poiché

potremmo avere più interfacce, sia remote che locali (interfaccia

Ethernet, Bluetooth, interfaccia Wifi ecc…) . Questo mi consente

di scambiare dati tra interfacce diverse. Banalmente si potrebbe

ricevere un interest da un’interfaccia Bluetooth e richiedere il dato

attraverso un’interfaccia ethernet o wifi o viceversa. Questo è

quello che accade oggi attraverso l’Ecdn ovvero il singolo

provider in questo caso YouTube, si iscrive alla Ecdn, offre il suo

servizio di dati attraverso la cdn e attraverso i vari internet service

provider, viene effettuato il delivery del dato a ogni singolo utente

(una singola replica del dato per ogni utente). Questo ovviamente

visto in larga scala si potrebbe creare il cosiddetto collo di

bottiglia.

Quello che, invece, immaginiamo possa accadere brevettando una

tipologia NDN, è una distribuzione del contenuto tra i vari interest

service provider e rendere il dato accessibile localmente ai

consumer, aggregare i consumer, suddividerli. Pensare, ad esempio,

di implementare delle cash e quindi avvicinare in qualche modo il

dato agli utenti senza sovraccaricare il provider principale.

Questo sono le differenze a livello architetturale tra IP e l’architettura

NDN. Notiamo come abbiamo un livello aggiuntivo chiamato Strategy

che si occupa di gestire il routing e le strategie di forwarding del

pacchetto.

Inoltre abbiamo un’altra differenza fondamentale che evidenziamo tra le

due architetture è l’implementazione dell’hedear di security

nativamente: non stiamo aggiungendo la sicurezza come funzionalità in

più come nel protocollo IP ma in questo caso la sicurezza è nativa,

garantita all’interno della rete. Non è qualcosa che dobbiamo inserire

come fosse un plug in. In questo caso il contenuto è reso sicuro, oltre

che la comunicazione è resa sicura.

2. DATA

STRUTTURA DEI PACCHETTI:

La struttura dei pacchetti è molto semplice:

-PACCHETTO INTEREST

 CONTENT NAME= in cui specifichiamo il nome del contenuto

 SELECTOR= possiamo eventualmente filtrare secondo opportune

politiche i contenuti che vogliamo ricevere

 NONCE=è un numero identificativo che identifica appunto l’interest che

sto inviando in maniera univoca. Il campo Nonce viene usato per fare

controlli sulle trasmissioni, sui duplicati dell’interest: guardando a parità

di interest con lo stesso nome, posso capire se uno stesso interest è stato

duplicato nella rete semplicemente confrontando il campo nonce. poiché

a interest diversi da consumers diversi deve corrispondere un nonce

diverso.

-PACCHETTO DATA

 CONTENT NAME= contiene lo stesso nome del contenuto che è stato

richiesto

 CAMPO SIGNATURE= nel quale viene memorizzato l’ash associato al

contenuto

 SIGNATURE INFO= altre informazioni relative a Publisher

 DATA= contiene il dato vero e proprio

Qui è raffigurata con maggior dettaglio quella che è una struttura di una applicazione

NDN con tutte e tre le strutture principali.

-CONTENT STORE: nome associato e dato. Il nome è di tipo gerarchico in cui il

primo campo rappresenta il provider che potrei banalmente identificare con il nome

del sito web (questo ovviamente è una stringa, un identificatore non si sta facendo

riferimento a un indirizzo ip). Il secondo campo, scendendo nell’albero, vi è il nome

del video , la categoria di video e poi negli ultimi campi si può specificare il mio

frame di interesse relativo al video. Nella seconda colonna abbiamo il dato vero e

proprio

-PENDING INTEREST TABLE (PIT): Abbiamo come chiave della entry il prefisso,

cioè il nome e l’interfaccia o le interfacce da cui il dato è stato richiesto poiché come

detto in precedenza abbiamo traccia dell’interest della PIT.

-FIB: Qui abbiamo il prefisso del nome e in questo caso specifichiamo uno dei prefissi

possibili di questo nome. Stiamo effettuando in questo caso una aggregazione

abbastanza alta perché utilizziamo solo il primo dei vari attributi del nome (quindi tutti

gli interest che avranno come suffisso parc.com, verrà effettuato il forwarding verso le

interfacce 0,1 o entrambe).

Supponiamo che un interest arrivi dall’interfaccia 0 (chiamata face): la prima

operazione è il check all’interno della cache. Se il dato è disponibile all’interno della

mia cache, il dato è rimandato verso la stessa interfaccia; se il dato non è disponibile

nella cache locale viene aggiunta la entry di riferimento nella PIT, viene lasciata una

traccia sul nodo. Ovvero mi è stato richiesto questo nome dall’interfaccia 0 e

successivamente effettuo il check nella FIB. Ovvero verifico se per questo

determinato nome ho un interfaccia di uscita disponibile verso il quale richiedere il

dato. In questo caso posso scegliere fra interfaccia zero o uno.

Le modalità secondo cui la scelta di questa interfaccia è effettuata sono molteplici e

questo fa parte sia dei protocolli di routing e sia delle forwarding strategy (ES: potrei

fare un ranking delle interfacce secondo vari parametri)

Banalmente come faccio a scegliere l’interfaccia 0 piuttosto che l’interfaccia 1,

potrebbe operare dei controlli periodici con entrambe le interfacce e valutare quale

delle due interfacce mi offre una latenza minore. Quindi all’interfaccia con latenza

minore, assegno un rank più alto. Quindi verrà preferita una interfaccia 0, a scalare

tutte le altre nel caso in cui l’interfaccia 0 non sia più disponibile.

Viene effettuato il forwarding dell’Interest, aggiornamento della PIT, e il pacchetto

arriva sull’interfaccia 1. Viene effettuato nuovamente il controllo nella PIT, ovvero si

controlla che per questo determinato DATA che è arrivano sull’interfaccia 1, c’era un

INTEREST pendente, quindi non era un dato insignificante, ma un dato che è stato

effettivamente richiesto, perché se così non fosse il dato è scartato, sta viaggiando un

pacchetto nella rete che è stato richiesto in realtà (anche per evitare attacchi a forza

bruta oppure immissione di dati inutili nella rete, quindi così solo i dati effettivamente

richiesti viaggiano nella rete. Quindi ho trovato la entry, l’interfaccia su cui ho

richiesto l’INTEREST era la 0, rimando il dato sull’interfaccia 0.

Insomma, il meccanismo di base della comunicazione NDN è questo

Questo è il caso che abbiamo già visto: più INTEREST possono essere aggregati su un

router per richiedere lo stesso dato;

stessa cosa dalla parte opposta: uno stesso dato può essere inviato in multicast a più

consumer e in aggiunta effettuare anche il cache.

Posso anche decidere se sono a conoscenza che diversi repository hanno la stessa

copia e lo diversi chank con lo stesso contenuto in maniera analoga (suppongo siano

parti del file stesso) e pensare di effettuare il forwarding dell’INTEREST

parallelamente a tutti i nodi che hanno quel dato disponibile. Questo ovviamente viene

effettuato a livello di strategy layer.

Una volta ricevuti tutti i chank del contenuto, li assemblo a livello di consumer.

Sicurezza del contenuto:

Come abbiamo visto, la sicurezza del contenuto viene fatta all’interno del pacchetto

data, dove abbiamo tutte le informazioni che ci servono per effettuare i dovuti

controlli, quindi il consumer può verificare quali sono i principi generali della

sicurezza (come verificare l’integrità del pacchetto semplicemente, nota la funzione di

hash e avendo l’hash del pacchetto data, posso semplicemente ricalcolare l’hash a

partire dal contenuto e vedere se l’hash calcolato da me e l’ash ricevuto combaciano ,

se combaciano il contenuto non è stato alterato durante il viaggio.

Posso anche verificare l'identità di chi mi ha inviato il dato e combinando il controllo

con altri campi specifici (come il nome) posso verificare anche la correttezza del dato

e verificare se il dato ricevuto è effettivamente quello che mi aspettavo.

Come abbiamo visto l’ICN, in particolare l’ NDN si basa sui nomi, ogni punto è

rappresentato secondo un nome con una stringa con vari elementi in un formato

leggibile e comprensibile ad occhio nudo. E’ chiaro che per quanto riguarda i nomi di

tipo gerarchico, ad esempio, l’NDN non limita la dimensione di questi nomi, quindi

potenzialmente potrei costituire un “name space” infinito, la struttura gerarchica

potrebbe avere una lunghezza variabile in maniere incontrollata. Questo potrebbe


PAGINE

91

PESO

1.73 MB

AUTORE

ValCan10

PUBBLICATO

9 mesi fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria gestionale (BARI, FOGGIA)
SSD:
A.A.: 2018-2019

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher ValCan10 di informazioni apprese con la frequenza delle lezioni di Fondamenti di internet e reti e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Politecnico di Bari - Poliba o del prof Grieco Luigi Alfredo.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Corso di laurea in ingegneria gestionale (bari, foggia)

Sistemi Informativi Modulo 1
Appunto
Metodi di Ottimizzazione
Appunto