A more technical presentation regarding QEST, as introduced by http://www.slideshare.net/matteocollina/making-things-that-works-with-us.

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

2. Outline
• Goal of this work
• QEST architecture
• Experimental results
• Current Issues
• Roadmap

3. http://www.flickr.com/photos/adactio/2337914481
50 billions
interconnected
"things"
by
2020

4. Scalability Issues
M2M protocols are mostly “Things” should interact with
ad-hoc, and researchers and our lives, and all the
businesses focus on low technology should be built to
level problems. make them easy to use.

5. • “things” exposed • “things” exposed
with binary protocol to the web
• publish/subscribe • request response
• topics as the naming • URIs as the
system naming system

6. speaks
speaks HTTP

7. HTTP Clients MQTT Clients
QEST
REST Server MQTT Server
• MQTT broker
QEST
• REST interface
• HTTP semantics Data Layer
• no QoS
• built on node.js
and redis Redis

8. state-of-art
state-of-art QEST-based QEST-based
approach to IoT apps IoT apps
approach to solution to IoT apps
solution to IoT apps
Web App Web App
Web App
Bridge
Web App
QEST
Bridge
QEST
IoT
Broker Device
IoT
Device
3 2 1 0 9 8 7 6 5 4 3 2 1 0
GND
SCL
AREF
SDA
1 1 1 1 DIGITAL
RX
TX
PWM
PWM
PWM
PWM
PWM
PWM
L
TX
Arduino UNO ON
Broker
RX
1
ICSP
www.arduino.cc
RESET
IOREF
POWER ANALOG IN
3V3
5V Gnd Vin 0 1 2 3 4 5
Device
3 2 1 0 9 8 7 6 5 4 3 2 1 0
GND
SCL
AREF
SDA
1 1 1 1 DIGITAL
RX
TX
PWM
PWM
PWM
PWM
PWM
PWM
L
TX
RX
Arduino UNO ON
1
ICSP
www.arduino.cc
RESET
IOREF
POWER ANALOG IN
3V3
5V Gnd Vin 0 1 2 3 4 5
Device

9. • use one pub/sub channel
for each topic
QEST • 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/

10. QEST : MQTT to REST
• retains every message received
client.publish("temp", "30");
• every topic has its own URI: /topics/<NAME>
curl -H "Accept: txt" http://qest.me/topics/temp

11. QEST : REST to MQTT
• transform every HTTP PUT received to a MQTT message
curl -X PUT -d '{ "payload": 42 }'
-H "Content-Type: application/json"
http://qest.me/topics/temp
• devices can listen directly to MQTT topics
void callback(char* topic, byte*
payload, int length) {
...
}
PubSubClient(server, 1883, callback);
client.subscribe("temp");

12. HTTP/MQTT Clients
How to Load Balancer
scale
REST Server MQTT Server REST Server MQTT Server
QEST
Data Layer
... QEST
Data Layer
Redis

13. 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.

14. • 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

15. We need OAuth
for devices!

16. 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.

17. Format Issues
Multiple solutions:
• use json-compatible formats
everywhere: ubjson, bison, ecc.
• add to MQTT a MIME-compatible
binary header to allow further
processing

18. Roadmap
• Support standard message brokers, like
RabbitMQ or ActiveMQ
• Improve the web interface
• Resolve format issues
• Propose a solution for the security issues

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