qest presentation for the eclipse foundation m2m iwg

Introducing the QEST broker

Matteo Collina (matteo.collina2@unibo.it)Giovanni Emanuele Corazza (giovanni.corazza@unibo.it)Alessandro Vanelli-Coralli (alessandro.vanelli@unibo.it)

Outline• Goal of this work

• QEST architecture

• Experimental results

• Current Issues

• Roadmap

50 billionsinterconnected

"things"by

2020

http://www.flickr.com/photos/adactio/2337914481

Scalability Issues

M2M protocols are mostly ad-hoc, and researchers and businesses focus on low level problems.

“Things” should interact with our lives, and all the technology should be built to make them easy to use.

• “things” exposed with binary protocol

• publish/subscribe

• topics as the naming system

• “things” exposed to the web

• request response

• URIs as the naming system

speaks

speaks HTTP

• MQTT broker

• REST interface

• HTTP semantics

• no QoS

• built on node.js and redis

QESTREST Server

Redis

MQTT Server

QEST

Data Layer

HTTP Clients MQTT Clients

Web App

DeviceSC

LS

DA

AR

EF

GN

D

IOR

EF

RE

SE

T3V

3P

WM

PW

MP

WM

L

TXRX ON

ICSP

PW

MP

WM

PW

M TX RX

31

21

11

01

9 8DIGITAL

7 6 5 4 3 2 1 0

1

5V GndPOWER

www.arduino.cc

ANALOG INVin 0 1 2 3 4 5

Arduino UNO

IoTBroker

QEST

state-of-artapproach to IoT apps

QEST-basedsolution to IoT apps

Bridge

Web App

Device

Web App

Device

IoTBroker

QEST

state-of-artapproach to IoT apps

QEST-basedsolution to IoT apps

Bridge

Web App

DeviceSC

LS

DA

AR

EF

GN

D

IOR

EF

RE

SE

T3V

3P

WM

PW

MP

WM

L

TXRX ON

ICSP

PW

MP

WM

PW

M TX RX

31

21

11

01

9 8DIGITAL

7 6 5 4 3 2 1 0

1

5V GndPOWER

www.arduino.cc

ANALOG INVin 0 1 2 3 4 5

Arduino UNO

QEST• use one pub/sub channel

for each topic

• has a global channel to support searches

• publishes newly created topics on the global channel, so old subscribers can interact with new topics

http://www.flickr.com/photos/jurvetson/5268677/

QEST• retains every message received

: MQTT to REST

curl -H "Accept: txt" http://qest.me/topics/temp

client.publish("temp", "30");

• every topic has its own URI: /topics/<NAME>

QEST• transform every HTTP PUT received to a MQTT message

: REST to MQTT

void callback(char* topic, byte* payload, int length) { ...}PubSubClient(server, 1883, callback);client.subscribe("temp");

curl -X PUT -d '{ "payload": 42 }' \ -H "Content-Type: application/json" \ http://qest.me/topics/temp

• devices can listen directly to MQTT topics

How to scale

Redis

HTTP/MQTT Clients

REST Server MQTT Server

QESTData Layer

...

Load Balancer

REST Server MQTT Server

QESTData Layer

Experimental Results

• We compared our MQTT implementation to the leading ones.

• QEST is slower, but the implementation is in javascript vs C.

• QEST performance is not affected by handling MQTT or HTTP.

• What devices can a user monitor?

• What devices can 'listen' to the state of other devices?

• Who can access the devices state?

• Is the communication secure?

Security Issues

We need OAuthfor devices!

Format Issues

• What data format the devices and the web can agree upon?

• Is possible that they could not agree?

• QEST currently tries to perform data format adaptation to and from JSON.

Multiple solutions:

• use json-compatible formats everywhere: ubjson, bison, ecc.

• add to MQTT a MIME-compatible binary header to allow further processing

Format Issues

Roadmap

• Support standard message brokers, like RabbitMQ or ActiveMQ

• Improve the web interface

• Resolve format issues

• Propose a solution for the security issues

Matteo Collina (matteo.collina2@unibo.it)

Thank You!Matteo Collina (matteo.collina2@unibo.it)

@matteocollina