mqtt: il protocollo che rende possibile l'internet of things

MQTT: il protocollo che rende possibile

l’Internet Of ThingsDavide Pozza – Omnys (www.omnys.com) davide.pozza@omnys.com http://it.linkedin.com/in/davidepozza

1

/42

Davide Pozza▪ Mi occupo di progettazione e delivery di infrastrutture software

“mission critical”

▪ Negli anni ho avuto modo di affrontare tematiche funzionali e tecnologiche relative agli ambiti più svariati tra cui: ▪ Internet banking ▪ Ecommerce ed integrazione con sistemi di legacy ▪ ICT e telecomunicazioni ▪ Interazione con dispositivi “smart”

▪ Sono socio di Omnys, software house presente sul mercato dal 09/09/1999 che si occupa principalmente di: ▪ System Integration e Architetture Cloud ▪ Piattaforme web (ecommerce, turismo, infomobilità, editoria digitale) ▪ APP mobile ▪ Internet of Things (wearable, medical, home automation)

2

/42

The Internet of Things

3

▪ Smartphone & wearable ▪ Controllo veicoli, persone,

animali, … ▪ Dispositivi embedded ▪ Automazione industriale ▪ Monitoraggio consumi

energetici ▪ Impianti di sicurezza e

sorveglianza ▪ Smart Building/Home & City ▪ Telemedicina e Salute ▪ Everyday things…

/42

Verso l’interconnessione totale

“The Web is becoming more and more pervasive as an applications platform, and effective standards are crucial for reducing the costs of

deploying applications across a wide range of devices and environments, whether in the office, at home or on the move.

The Ubiquitous Web will provide people with access whenever and wherever they find themselves, with applications that dynamically

adapt to the user's needs, device capabilities and environmental conditions.”

Philipp Hoschka, Ubiquitous Web Domain Leader

Ubiquitous Web

Web 1.0 Web 2.0 Social WebMobile Web

4

/42

Una crescita esponenzialeA fine del 2014: 9 miliardi di dispositivi connessi

Entro il 2020:

• 57.000/secnuovi dispositivi che si connetteranno

• 212 miliardidi dispositivi in grado di connettersi

• 30 miliardidi dispositivi connessi

5

/42

Internet of Things: il problema

Persone + Oggetti + Sensori + Dispositivi =

tantissimi endpoint che emettono segnali

6

/42

Internet of Things: una nuova sfida▪ Richiede un modello di

comunicazione in real-time ed event-driven

▪ Le informazioni devono poter essere inviate in modalità one-to-many

▪ Capacità di recepire (“listening”) un evento non appena si verifica

▪ Necessità di ridurre al massimo la dimensione dei pacchetti dati scambiati

▪ Necessità di gestire l’invio di messaggi anche su reti degradate (reliability)

7

/42

L’HTTP è adatto per gestire SEGNALI?

▪ E’ “document-centric” (XML, ecc) e basato sul paradigma request/reply

▪ Ha un elevato overhead di rete ▪ E’ estremamente verboso: PUT/POST/GET/DELETE prevedono

comunque l’invio di molti bytes e non sono sempre la scelta migliore nello sviluppo di applicazioni dove la comunicazione deve essere “ultralight”

▪ Non prevede nessuna garanzia built-in sulla comunicazione

8

/42

Internet of Things: non è il WEB!▪ I firmware dei dispositivi

sono limitati (potenza, memoria, batteria)

▪ Possono essere necessari anche migliaia di dispositivi per monitorare un sistema industriale (es. gasdotti, piattaforme petrolifere,…)

▪ La connettività può essere molto degradata e/o estremamente costosa (GPRS, Satellite)

9

/42

L’alternativa

MQTT = MQ TELEMETRY TRANSPORT

“A light weight event and message oriented protocol allowing devices to asynchronously communicate efficiently across constrained

networks to remote systems”

10

/42

MQTT: i principali benefici▪ Rende semplice la connessione tra il

mondo degli oggetti e il mondo dell’ IT evitando il “polling” dei sensori

▪ Consente la trasmissione di dati su reti soggette a frequenti interruzioni

▪ Fornisce il massimo disaccoppiamento possibile garantendo comunque la trasmissione/ricezione dei dati (QoS)

▪ Riesce a gestire la comunicazione con un elevato numero di dispositivi

11

/42

Il protocollo MQTT in SINTESI• Semplice: solo 3 funzioni:

– connect + publish + subscribe (un client può funzionare su un controller a 8 bit e 256kb di RAM)

• Affidabile: QoS per supportare reti degradate

• Leggero: overhead minimo ed estrema efficenza: – no envelope, o headers; pacchetti anche da 2 bytes

• Aperto: standard definito e aperto (royalty-free)

12

/42

Il trend di interesse per l’MQTT

Google Trends evidenzia un interesse in forte crescita in relazione al termine “MQTT”

13

/42

Ambito dell’MQTT

Intelligence & AnalyticsTraditional Backend Systems BigData

Interconnection

Mobile & Web Embedded Controllers, Sensors, Actuators, …

Data/Alert

Respond

Control

Sense

14

/42

Il modello Publish/Subscribe▪ Il PUBLISHER invia (publish) un

messaggio su un TOPIC (subject)

▪ Il SUBSCRIBER è un consumer che si mette in ascolto (subscribe) sui messaggi pubblicati su un TOPIC specifico

▪ Il BROKER (server di smistamento messaggi) si occupa di effettuare il matching tra SUBSCRIBER e PUBLISHER con il conseguente dispatching del messaggio.

Subscriber

Broker

Publisher

Topic

Publisher

Topic Subscriber

Subscriber

15

/42

Comunicazione asincrona e bidirezionale

MQTT Broker

1. CONNECT to MQTT broker 2. PUBLISH on:

<house_id>/s/energyConsumption <house_id>/s/solarEnergy

3. SUBSCRIBE to: <house_id>/thermostat/setTemp

1. CONNECT to MQTT broker 2. SUBSCRIBE on:

<house_id>/s/* 3. PUBLISH to:

<house_id>/thermostat/setTemp

16

/42

Garanzia nella comunicazione

▪ Keep-Alive message (PINGREQ, PINGRESP): – il Broker riesce ad identificare una disconnessione non

esplicita del client

▪ Will message: – viene impostato nel messaggio di CONNECT con topic, QoS

e retain. In caso di disconnessione inaspettata il messaggio “Will” viene mandato ai subscribers registrati

▪ Retain message: – un messaggio pubblicato su un topic viene mantenuto sul

broker. Un successivo subscriber che si connette sullo stesso topic riceve il messaggio (last known good message)

▪ Persistent Session: – dopo la disconnessione del client, tutte le sottoscrizioni

vengono mantenute nel broker e recuperate alla connessione successiva

17

/42

Cos’è il livello di qualità del servizio (QoS) ?E’ un “agreement” tra il mittente ed il destinatario di un messaggio in

relazione alla garanzia di “delivery” del messaggio stesso.

Il QoS è una delle più potenti caratteristiche del protocollo MQTT in quanto rende molto più semplice lo scambio messaggi su reti degradate attraverso la gestione automatica della ri-trasmissione.

Ci sono tre livelli disponibili: ▪ QoS 0 – at most once: garantisce il “best effort delivery”; è detto anche

“fire & forget” e non contempla la conferma di ricezione che quindi è la medesima del trasporto TCP/IP

▪ QoS 1 – at least once: garantisce la consegna del messaggio almeno una volta verso un ricevente; il messaggio però può essere ricevuto anche più volte

▪ QoS 2 - exactly once: garantisce la consegna del messaggio una ed una sola volta verso un ricevente

18

/42

Come funziona il QoS

BrokerPublisher Subscriber

BrokerPublisher Subscriber

PUBLISH (QoS = 0)PUBLISH

Delete message

Store message

PUBLISH (QoS = 1)

Store message

Delete message

Delete message

PUBLISH

BrokerPublisher Subscriber

Store message

PUBLISH (QoS = 2)

Store message

Delete message

Delete message

PUBLISH

QoS 0: At most once (fire & forget)

QoS 1: At least once QoS 2: Exactly once

PUBREC

PUBREL

PUBCOMPPUBACK

19

/42

Sicurezza nella comunicazione3 livelli di sicurezza:

▪ PROTOCOLLO ▪ Username/Password in CONNECT ▪ Possibilità di criptare il Payload

▪ TRASPORTO ▪ MQTT over TLS (v1.2) ▪ Autenticazione del client con certificato

▪ BROKER ▪ Gestione dei permessi su Publish/Subscribe e Topic ▪ Possibilità di integrare altri sistemi di autenticazione/autorizzazione (es. LDAP, OAuth

2.0)

20

/42

MQTT vs HTTP (long polling): prestazioni

Test di spedizione (1024 messaggi con payload da 1 byte)

http://stephendnicholas.com/archives/121721

/42

MQTT vs HTTP: la struttura del messaggio

MQTT: dimensione header 2 byte

HTTP: dimensione headerREQ/RES > 300 byte

22

GET /service Host: www.endpointm2m.com Accept:text/xml Accept-Encoding:gzip, deflate, sdch Connection:keep-alive

HTTP/1.1 200 OK Connection:Keep-Alive Content-Length:33452 Content-Encoding:gzip Content-Type:text/xml Keep-Alive:timeout=15, max=100 Last-Modified:Fri, 17 May 2013 14:50:39 GMT Connection:close

/42

MQTT-SN▪ E’ un’evoluzione dello standard MQTT pensata per i dispositivi

embedded (SN = Sensor Networks) ▪ Non richiede lo stack TCP/IP: può essere utilizzato su seriale, UDP,

ZigBee, RF, …

23

/42

MQTT … in pratica

24

/42

I principali Broker MQTT

MOSQUITTO

25

/42

Soluzioni MQTT in Cloud

▪ Pagamento a consumo di risorse (“pay per usage”)

▪ Opzione “free tier”: sotto soglie ben definite il servizio è gratuito

▪ Soluzioni IaaS / PaaS ▪ Elevati QoS (99.9%) ▪ Elevata scalabilità ▪ Tempi di startup estremamente ridotti

26

/42

IBM Bluemix

▪ Sul fronte dei servizi Cloud MQTT/IoT sono i primi arrivati (GIU-14), nonché i principali promotori e ideatori dello standard MQTT

▪ Fornisce un soluzioni “full stack” (boilerplate), tra cui quella dedicata esclusivamente all’ IoT e basata su MQTT

▪ Basata su CloudFoundry con deploy in 3 step: ▪ Selezione di un Runtime (Node, Java, PHP, …) ▪ Selezione dei Servizi ▪ Installazione dell’applicazione

▪ Freemium plan: ▪ 20 dispositivi ▪ 100MB di traffico dati al mese ▪ 1GB di storage

27

/42

IBM Bluemix

28

/42

Amazon AWS IoT: overview

▪ Offre la più elevata quantità di servizi Cloud dislocati in ben 11 regioni geografiche e vanta la miglior offerta in termini di scalabilità e computazionalità

▪ AWS, nato nel 2006, solo pochi giorni fa (OTT-15) ha lanciato la soluzione “AWS IoT” (attualmente in “Beta”) che sfrutta il protocollo MQTT

▪ Free tier of 250K messages (IN/OUT) per month for 12 months. Therefore 5$ per million messages

29

/42

Amazon AWS IoT: caratteristiche

30

/42

Microsoft Azure IoT Suite

▪ La Suite IoT è stata lanciata molto recentemente (MAR-15) ▪ Microsoft ha dichiarato di puntare molto sull’IoT (Windows 10 for

Raspberry Pi) ▪ L’approccio è quello di mettere a disposizione “finished

applications to speed development of common scenarios” ▪ E’ possibile utilizzare il protocollo MQTT solo come layer

aggiuntivo in quanto non è incluso come soluzione nel “core” della Suite.

31

/42

Eurotech

▪ La suite EDC (Everywhere Device Cloud - iPaaS) fornisce una soluzione completa (HW & SW) che offre la connettività sicura e scalabile basata su MQTT

▪ La suite ESF (Everywhere Software Platform) è un framework finalizzato a rendere il più semplice possibile l’integrazione tra i dispositivi ed il cloud (EDC)

▪ Utilizza un’enhanced version del protocollo MQTT che ad esempio può gestire la “birth date” del dispositivo

▪ Modello di pricing basato su numero di dispositivi e/o numero di messaggi scambiati

▪ La suite può funzionare su AWS, Azure o anche in modalità standalone

32

/42

Eurotech EDC/ESF

33

/42

Client di riferimento MQTTDisponibile per i seguenti linguaggi: ▪ C++ ▪ C for embedded ▪ Go ▪ Java ▪ JavaScript ▪ Lua ▪ .Net ▪ Objective-C ▪ Python

Altri: https://github.com/mqtt/mqtt.github.io/wiki/libraries

• Client di riferimento per l’ecosistema MQTT

• Disponibile open-source

34

/42

Alcuni casi d’uso

35

/42

Monitoraggio oleodotti e piattaforme

36

/42

Facebook Messenger

▪ More than 850M Users ▪ Chat application ▪ Improved Battery ▪ Lower latency ▪ Less bandwidth

https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920

“By maintaining an MQTT connection and routing messages through our chat pipeline, we were able to often achieve phone-to-phone delivery

in the hundreds of milliseconds, rather than multiple seconds.”

37

/42

Una “smart home” open source

▪ Mosquitto MQTT + openHab su Raspberry Pi ▪ Arduino per la gestione dei sensori ▪ Monitoraggio e controllo remoto da tablet/

smartphone con app openHab

http://www.instructables.com/id/Uber-Home-Automation-w-Arduino-Pi

38

/42

Infomobilità e autotrasporti

▪ Ogni mezzo dispone di un device che raccoglie e invia i dati su posizione, velocità e consumi

▪ I dati raccolti vengono inviati “dove serve” ▪ Le informazioni sono analizzate e le decisioni sono prese in tempo reale da

un singolo backend

39

/42

Salute e medicina

▪ Ogni dispenser comunica con il server centrale in tempo reale inviando dati su mancate/errate assunzioni

▪ Le informazioni relative ad eventi di allarme scatenano delle azioni immediate (notifica telefonica, SMS, ecc)

1.ilpazientenon assumeilfarmaco

2.Ildispositivoinviaallarmealservercentrale(MQTToverGPRS)

3.Ilservercentrale(broker)invianotificaistantaneaalmedico

4.Ilmedicocontattailpaziente

40

/42

Credits▪ MQTT official web site : http://mqtt.org ▪ Mosquitto : http://mosquitto.org / https://www.eclipse.org/mosquitto ▪ Mosca: https://github.com/mcollina/mosca ▪ HiveMQ : http://www.hivemq.com ▪ M2Mqtt C# Client : http://m2mqtt.codeplex.com ▪ Eclipse Paho project : http://www.eclipse.org/paho/ ▪ MQTT-SN: http://mqtt.org/2013/12/mqtt-for-sensor-networks-mqtt-sn ▪ Amazon AWS IoT: https://aws.amazon.com/iot/ ▪ IBM Bluemix IoT: https://www.ibm.com/cloud-computing/bluemix/solutions/iot/ ▪ Microsof Azure IoT Suite: http://www.microsoft.com/en-us/server-cloud/internet-of-things/ ▪ Eurotech: http://www.eurotech.com/

41

/42

Grazie per l’attenzione!

DOMANDE ?

42

OMNYS-InformationTechnologywww.omnys.com

@SMAUMilano2015:PAD.1-STANDE11