qest presentation for the eclipse foundation m2m iwg
DESCRIPTION
A more technical presentation regarding QEST, as introduced by http://www.slideshare.net/matteocollina/making-things-that-works-with-us.TRANSCRIPT
Introducing the QEST broker
Matteo Collina ([email protected])Giovanni Emanuele Corazza ([email protected])Alessandro Vanelli-Coralli ([email protected])
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