The document discusses why HTTP is not well-suited for Internet of Things (IoT) applications compared to MQTT. HTTP requires that the client and server be continuously available for request/response, while MQTT uses a broker to decouple publishers and subscribers, allowing asynchronous communication even when devices are intermittent. MQTT also supports features like publish/subscribe messaging with topics, quality of service guarantees, and retained messages that make it more robust for constrained IoT devices and unreliable networks.
10. HTTP
Consumer must be available at all times
Publisher needs to know the exact
destination
Publisher depends on the response
status
11. MQTT
Broker must be available at all times
• Doesn’t do any processing, failure is uncommon
Publisher and subscriber are decoupled
• Publisher publishes at it’s leisure
• Subscriber processes messages at it’s leisure
Publisher does not care who (if anyone) it’s publishing to
Publisher doesn’t care about the result of processing
12. Quality of Service (QoS)
0 – fire and forget
1 – Guaranteed delivery at least once
2 – Guaranteed delivery exactly once
• Can be easily implemented client-side by
using QoS 1 to increase throughput
13. Topics
Hierarchical
• a/b/c
• com.example/sensors/sen546/temp
• CTL/com.example/sensors/sen546
“+” matches single level
• com.example/sensors/+/temp
• +/sensors/sen546
“#” matches many level, must be at end
• com.example/sensors/#
• CTL/com.example/#
14. MQTT Features
Last will and testament
• Unexpected disconnects
Retained messages
• Infrequently published values
23. We power the connected enterprise
• 2lemetry is an IoT technology and solutions company that
powers the connected enterprise, tying people, processes, data
and devices together—transforming raw data into real-time
actionable intelligence.
• Founded 2011—spun off from hardware manufacturer
• 100% Focus on Internet of Things—with a “cloud first” focus
25. 2lemetry technology, solutions, partners and expertise
to provide an end to end solution
Technology
2lemetry Device Cloud Platform
Solutions
Enterprise system
integration tools
Digital signage
Proximity sensing
Facial recognition
Partners
Across entire IoT
project lifecycle
Sales channel
Expertise
IoT strategy
Integration expertise and
application development
Managed service and
support
CONFIDENTIAL - 2lemetry, LLC
Editor's Notes
Disclaimer: I work for 2lemetry but these opinions are formed out of personal experiences and won’t affect 2lemetry’s business either way
I’m a software engineer – distributed systems, web apps, EAI
I prefer simple systems because they scale better (in every way)
Equation works for value propositions, problems, and other aspects
Take a while explaining what’s meant by IoT – people at DF don’t seem to be well-educated on it
Device cardinality – any small task becomes hard when you have 1 million devices
Next slide contains pics of devices
Make sure to mention 2-4k of memory, 8-bit vs 32-bit processors
Network connectivity problems
Packet loss
Packet size limitations
C64 – could address 64K of memory (8-bit CPU)
MEMS devices
Data flows from sensors to the cloud
“IoT” is often used as a synonym for “big data” – IoT scale versus web scale
Sensors => actuators
Sensors => cloud (this is the one we’re usually interested in)
The broker insulates the publisher from errors in the subscriber
Take a moment to describe why HTTP isn’t working (text-based, large packet sizes)
Next slide is talking about why request/response doesn’t work
We assume everyone in the room understands this model
“consumer” = server
“publisher” = HTTP client using POST or PUT to send data
CoAP-MQ
Want to show this with application layer on top
Need to point out advantages here
Don’t buy IoT -> they buy the solution behind it -> Invisible revolution