IoT, la scelta del protocollo

4 luglio 2014

Nelle lezioni precedenti abbiamo affrontato questioni legate alla connessione a Internet con un accenno alla Internet Of Things. Nella prossima lezione ci concentreremo sulla realizzazione di un progetto IoT, ma prima è interessante soffermarci sulle la modalità e i protocolli di comunicazione che sfrutteremo e sulle possibili scelte a disposizione.

HTTP/REST, la scelta più comune ma non sempre la migliore

Uno dei protocolli maggiormente utilizzati per la connessione dei device al Cloud è il protocollo HTTP attraverso l’architettura REST (REpresentation State Transfer). Sarà proprio questa la modalità di connessione che utilizzeremo più avanti in un caso pratico, ma va detto che può non essere considerata la migliore, in particolare nel nostro caso.

HTTP è un protocollo ASCII e puramente testuale che si basa sul pattern request/response ma che soprattutto tende a trasferire troppe informazioni di “contorno”, come ad esempio gli header, in relazione al reale contenuto informativo incluso nel body (anche se in alcuni modelli, le informazioni possono essere trasferite anche attraverso headers “custom” non standard e senza alcun body).

Spesso, la quantità di dati da manipolare è un problema per un device embedded soprattutto in termini di memoria e può contemporaneamente determinare un aumento dei costi durante il trasferimento nel caso, per esempio, di una connessione GPRS e quindi di un traffico dati attraverso una SIM.

HTTP resta indubbiamente il protocollo più comune e ciò può risultare utile soprattutto nel caso di applicazioni su tablet o smartphone che accedono al Cloud per mostrare all’utente finale i dati acquisiti.

MQTT e altri protocolli

Dal punto di vista dei device che devono trasmettere dei dati, può invece non essere la scelta migliore: nell’ambito dell’Internet of Things si stanno affermando, sempre più numerosi, altri protocolli soprattutto “binari” che, non solo hanno un pattern diverso noto come publish/subscribe, ma soprattutto garantiscono un trasferimento minimo di byte “inutili” rispetto al contenuto informativo. Tra i più noti ci sono:

  • MQTT (Message Queue Telemetry Transport) nato proprio per la “telemetria”, molto leggero ed affidabile (garantisce tre livelli differenti di QoS) soprattutto su reti non perfette in termini di stabilità della connessione.
  • AMQP (Advanced Message Queuing Protocol), nato soprattutto per la connessione “server to server” e quindi per sistemi enterprise, più “pesante” di MQTT ma con il supporto a numerosissimi pattern differenti.

Ad essi si aggiungono anche i vari XMPP, DDS, STOMP e così via. Per gli amanti dell’HTTP, ma che comunque vogliono evitare il suo “enorme” peso, c’è il protocollo CoAP (Constrained Application Protocol) che è HTTP-like, basato sul pattern request/response, su UDP (in luogo di TCP) ma soprattutto “binario” e quindi più leggero.

Nell’ambito di questa ampia varietà di protocolli, la scelta dell’uno rispetto ad un altro dipende sempre dal tipo di applicazione da realizzare ed in moltissimi casi si tende ad utilizzarne sempre più di uno. Un’analisi di questo tipo occuperebbe una guida intera e per questo motivo, utilizzeremo per maggiore semplicità il protocollo HTTP.

Tutte le lezioni

1 ... 7 8 9

Se vuoi aggiornamenti su IoT, la scelta del protocollo inserisci la tua e-mail nel box qui sotto:
Tags:
 
X
Se vuoi aggiornamenti su IoT, la scelta del protocollo

inserisci la tua e-mail nel box qui sotto:

Ho letto e acconsento l'informativa sulla privacy

Acconsento al trattamento di cui al punto 3 dell'informativa sulla privacy