Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (13)
Similar to Why HTTP Won't Work For The Internet of Things (Dreamforce 2014)
Similar to Why HTTP Won't Work For The Internet of Things (Dreamforce 2014) (20)
More from kellogh
Recently uploaded
Recently uploaded (20)
Why HTTP Won't Work For The Internet of Things (Dreamforce 2014)
- 1. Why HTTP Won’t Work For IoT Tim Kellogg Principal Software Engineer @kellogh
- 2. About Me Backend Cloud Services Simple Designs Abstractions Are Good
- 3. Internet of Things Embedded Internet IoT
- 4. Internet of Things Constrained environments • Constrained memory footprint MCUs • Embedded Linux • No OS Unreliable network connectivity
- 6. Telemetry Device to server Sensor readings Big data & analytics
- 7. Telemetry Publish Broker Cloud Connectors Subscribe Salesforce1 Platform Devices Sensors
- 8. HTTP For request / response
- 9. HTTP Request Client Server Response
- 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
- 15. MQTT-SN MQTT for Sensor Networks UDP + 6LoWPAN Gateway Configuration-free discovery
- 17. CoAP A lighter version of HTTP with some extra bells and whistles
- 18. Constrained Application Protocol REST HTTP mappings for proxy servers Very lightweight messages UDP + 6LoWPAN Confirmable messages
- 19. GET+Observe Additional response messages sent whenever the resource changes No polling
- 20. Resources IoT Zone MQTT & CoAP • http://iot.eclipse.org/ • https://app.thingfabric.com/ Hardware • http://www.kelloggsresearchlabs.com/PressReleaseGenerator
- 21. @kellogh
- 22. APPENDIX CONFIDENTIAL - 2lemetry, LLC
- 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
- 24. Technology - ThingFabric Broker Layer Data Storage Rules Engine CEP Engine REST API Regional Load Balancing • Historical data storage • Automation replication • Schemaless • Find trends • Run computations • Build complex models • HTTP webhook • Republish rules • SMS/Email • Reformat payloads • Supports custom protocols • Supports MQTT, Stomp, CoAP • Balanced by geographical response time
- 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