Comunicazione IoT: una rete intelligente ovvero MQTT spiegato (bene) per non addetti ai lavori

Il Protocollo MQTT spiegato in modo semplice e chiaro per i non addetti ai lavori.

1 – Lo scenario

Immaginiamo di essere in un ristorante di Sushi, quelli con il nastro trasportatore che gira per l’intera sala.

Siamo andati con un gruppo nutrito di amici e ci rendiamo conto che su alcuni tavoli manca la salsa di soia mentre su altri manca il wasabi e c’è una sola bottiglia di salsa di soia senza sale in tutto il locale.

2 – L’approccio HTTP

Se dovessimo gestire la situazione seguendo il protocollo HTTP dovremmo agire come segue:

1. Quando qualcuno ha bisogno della salsa di soia, chiede al cameriere: “Potrei avere della salsa di soia?”.
2. Il cameriere risponde: “Al momento non ne ho più”, e se ne va.
3. Un cliente gentile, rendendosi conto che non sta più usando la salsa di soia, chiama il cameriere e gli dice: “Se vuole, può prendere questa salsa di soia perché a me non serve più”.
4. Il cameriere prende la salsa di soia e la riporta al suo posto ma non avvisa nessuno della nuova disponibilità di salsa di soia.
5. Se qualcuno ha bisogno della salsa di soia, chiede al cameriere e quello gli risponde: “Sì, adesso me ne hanno data una!”, e consegna quella fornita gentilmente dal cliente cortese del punto 3.

In questo caso i client(i) del ristorante devono rivolgersi necessariamente al cameriere (il server!) quando hanno bisogno di qualcosa, oppure quando vogliono consegnargli le salse che non stanno usando e che potrebbero essere utili ad altri avventori. Questo, tuttavia, accade senza che vi sia mai una comunicazione tra i presenti in sala, che hanno come unico riferimento il cameriere.

3 – L’approccio MQTT

Se dovessimo gestire la situazione seguendo il protocollo MQTT potremmo invece agire come segue:

1. Quando qualcuno non usa più una salsa, la mette sul nastro trasportatore;
2. Se qualcuno ha bisogno di quella salsa, la prende dal nastro trasportatore;

In questo caso il nastro trasportatore è il broker e i client(i) mettono e prendono quello che vogliono sul nastro in modo da condividere risorse e informazioni.

4 – Quando usare HTTP

Non è sempre detto che usare il nastro trasportatore sia un metodo efficace per ottenere quello di cui si ha bisogno. Per esempio, se un client(e) volesse delle bacchette nuove, non potrebbe certo prendere quelle usate da qualcun altro; se volesse chiedere il conto, non potrebbe certo essere un commensale a gestire la cassa. Ci sarà per forza bisogno di un cameriere che riceva le richieste dei client(i) e le gestisca singolarmente.

HTTP dunque ha senso quando:

1. Serve qualcosa (le bacchette) che gli altri commensali non possono dare.
2. Serve che si faccia un’azione (preparare il conto) per tutti i clienti e che richiede dei calcoli centralizzati.
3. Serve una risposta rapida con tempistiche definite: se per esempio devo andare urgentemente alla toilette, non posso aspettare che ci vada qualcun altro per poi farmi dire dove si trova: dovrò chiedere al cameriere dove si trova il bagno e il cameriere fornirà una risposta specifica e rapida alla mia domanda.

Detta in termini più tecnici le domande di base sono:

1. Chi ha i dati che mi servono?
2. Chi è il responsabile dell’elaborazione delle informazioni che mi servono?
3. Che tipo di risposta mi serve?

Sul nastro trasportatore i clienti possono condividere delle risorse e compiere piccole azioni (ad esempio un commensale gentile potrebbe sbucciare i mandarini per tutti e poi rimetterli sul nastro già sbucciati), ma se serve l’intervento di forze esterne (le bacchette nuove, il conto, la posizione del bagno ecc.) ci sarà sempre bisogno di un server a cui rivolgere le chiamate specifiche.

5 – Simulare HTTP con MQTT

I più ingegnosi di voi potrebbero aver pensato che si possa usare il nastro trasportatore anche per comunicare con il cameriere, ad esempio scrivendo un bigliettino con la richiesta per poi metterla sul nastro aspettando che il cameriera la veda, la legga e lasci a sua volta sul nastro trasportatore una risposta (delle bacchette nuove, il conto, un bigliettino con le indicazioni per il bagno ecc.).

Questo tipo di approccio presenta evidenti problemi:

1. È eccessivamente macchinoso rispetto all’interazione diretta con il cameriere.
2. Sia le richieste che le risposte passano sotto il naso di tutti, e questo potrebbe non essere desiderato (ad esempio chi paga il conto vorrebbe poter offrire lui, quindi non vuole che altri possano mettere le mani sul conto e passargli davanti).
3. Si deve aspettare che il messaggio arrivi al cameriere, che questi lo legga, che scriva la risposta e che la risposta arrivi al richiedente e non c’è garanzia che ciò avvenga in tempi brevi. Interagire direttamente col cameriere dà la sicurezza che ad un certo punto il cameriere risponderà.

In concreto, simulare un’interazione del tipo domanda-risposta (HTTP, domanda al cameriere) con la condivisione diretta di risorse (MQTT, nastro trasportatore) è solitamente sconsigliato ed eccessivamente complesso.

6 – Quando usare MQTT

I più ingegnosi di voi potrebbero aver pensato che si possa usare il nastro trasportatore anche per comunicare con il cameriere, ad esempio scrivendo un bigliettino con la richiesta per poi metterla sul nastro aspettando che il cameriera la veda, la legga e lasci a sua volta sul nastro trasportatore una risposta (delle bacchette nuove, il conto, un bigliettino con le indicazioni per il bagno ecc.).

Questo tipo di approccio presenta evidenti problemi:

1. È eccessivamente macchinoso rispetto all’interazione diretta con il cameriere.
2. Sia le richieste che le risposte passano sotto il naso di tutti, e questo potrebbe non essere desiderato (ad esempio chi paga il conto vorrebbe poter offrire lui, quindi non vuole che altri possano mettere le mani sul conto e passargli davanti).
3. Si deve aspettare che il messaggio arrivi al cameriere, che questi lo legga, che scriva la risposta e che la risposta arrivi al richiedente e non c’è garanzia che ciò avvenga in tempi brevi. Interagire direttamente col cameriere dà la sicurezza che ad un certo punto il cameriere risponderà.

In concreto, simulare un’interazione del tipo domanda-risposta (HTTP, domanda al cameriere) con la condivisione diretta di risorse (MQTT, nastro trasportatore) è solitamente sconsigliato ed eccessivamente complesso.

7 – Topic MQTT

Nella nostra analogia del ristorante, il nastro trasportatore rappresenta il broker MQTT che consegna a tutti i client(i) del locale una risorsa che gli è stata affidata.

Così facendo, però, tutti i client(i) del locale si vedrebbero passare sotto il naso tutte le cose che chiunque mette sul nastro trasportatore: le varie pietanze, i mandarini sbucciati, le bacchette, la salsa wasabi, la salsa di soia, la soia senza sale ecc. e dovrebbero perdere tempo per capire se ciò che sta passando sul nastro è quello che effettivamente serve loro in quel momento (ad esempio leggere sull’etichetta di tutte le bottiglie di soia per individuare quella senza sale).

Un broker MQTT in realtà è un meccanismo più avanzato di un semplice nastro trasportatore e, anzi, consente di creare un nastro trasportatore dedicato per ogni tipo di risorsa. Quindi facciamo un esempio:

1. Un nastro trasportatore dedicato alle salse;
2. Un nastro trasportatore dedicato ai mandarini;
3. Un nastro trasportatore dedicato alle pietanze.

Questa lista potrebbe essere ulteriormente espansa:

1. Un nastro trasportatore dedicato alle salse:
   1. un nastro trasportatore dedicato alla soia (salata e non)
      1. un nastro trasportatore per la sola soia non salata
   2. un nastro trasportatore dedicato al wasabi
2. un nastro trasportatore dedicato ai mandarini (sbucciati e non):
   1. un nastro trasportatore per i soli mandarini sbucciati
3. un nastro trasportatore dedicato alle pietanze:
   1. un nastro trasportatore per il sushi
   2. un nastro trasportatore per le insalate
   3. un nastro trasportatore per i dolci
   4. …

In questo modo, chi ha bisogno della salsa di soia non salata tiene un occhio sul nastro trasportatore (topic) relativo e si attiva solo quando vede passare qualcosa perché saprà che quella è una salsa di soia senza sale che è quello di cui aveva bisogno.

Si noti che nell’MQTT la stessa bottiglia di salsa di soia non salata che passa sul nastro dedicato alla soia non salata passerà comunque anche su quello della salsa di soia generica, su quello delle salse generiche e sul generico nastro “globale” in cui passa ogni cosa.

In questo senso, quindi, i topic (nastri trasportatori dedicati) sono come dei filtri che servono a limitare la tipologia di risorse che chi osserva vede passare. In questo modo chi osserva il nastro trasportatore può decidere di veder passare solo ciò a cui è interessato.

Vuoi avere maggiori informazioni su come sviluppiamo App IoT in DuckMa?