[FoRK] PubSub NG Re: MQTT : Exploring the Protocols of IoT - News - SparkFun Electronics
Stephen D. Williams
sdw at lig.net
Fri Feb 27 15:21:40 PST 2015
I'm working on other things and haven't surveyed the state of this area recently, but given a lot of other background, off the top
of my head:
Security: authentication, authorization, reliability (also see comments below)
Configuration: Messages, settings
Data: Bulk, periodic, streaming, subscription
Power: Timed intermittent, beaconing, low-power monitoring
Timing: synchronization, clock, time
Error: best effort vs. reliable, watchdog, recovery / restart, reliable firmware update w/ security and rollback
The same protocols and connectivity should be usable via:
Standard chip interconnects: MIPI/I2C, SPI
Bluetooth / Zigbee / etc.
Wifi / ethernet
USB / etc.
It would be good to have a very thin, dumb register/variable get/set, request, and send/receive data mode. Then higher level
packet-based options on top of or next to those. Security ought to be somehow done as an independent layer so that it can be
replaced, fixed, done as a separate chip, etc.
Everything should be encrypted, signed, nonced, timestamped, and strongly protected under one or more security modes.
It ought to be possible to configure a device in simple shared key mode and alternately strong PKI/GPG modes. TLS (HTTPS, SSH,
etc.) is probably going to be preferred for at least some modes.
Need to avoid having slow devices slow down channels for fast devices.
Need to balance power vs. bandwidth.
Need to balance at-limit distance communication with dense clouds of devices all communicating at once, perhaps on many different
private and public networks.
Should support private, hidden as possible, and levels of public mesh, broadcast, unicast, etc.
Ideally, should support direct web-browser use or debugging, probably as an option, maybe via a standard mapping proxy.
Having good flexible security with minimal hardware, power, and time is the fundamental hard part. Everything else can be done with
well thought out solutions.
this should be done through some type of conceptual module system. Then, a lower level device could be boosted by layering a module
near / on it. Security could be done this way: Really dumb devices could use very simple but effective security which is paired
with a smarter device that does PKI etc.
On 2/27/15 11:11 AM, J. Andrew Rogers wrote:
>> On Feb 27, 2015, at 8:58 AM, Stephen D. Williams <sdw at lig.net> wrote:
>> That sounds like a good idea. Or a Wiki page somewhere, perhaps on Github with an associated project.
>> What are the currently perceived requirements, constraints, and best practices?
> The physical constraints are power and bandwidth for platforms that are operating at very high raw data rates. The weakest silicon typically embedded in these platforms is recent 32-bit ARM and 64-bit Intel is increasingly common. You need quite a bit of beef at the edge.
> The network is high latency but often locally high bandwidth, so TCP is right out. There is not enough bandwidth or too much latency to push all coordination and logic into a data center. The topology is decentralized, mobile, somewhat ad hoc, and needs to be spatially aware. Not exactly like a mesh network but with similar routing challenges. Lots of authentication concerns. There are some interesting use cases for blockchain-style technology here.
> Wire format does not need to be over-engineered but it does need to be efficient, compact, and binary. Versioning yes, complex schemas no. Data rates are way too high to do any kind of complex schema wrangling — few people ever check as it is. Wire formats designed to support vectorizable encode/decode — typical silicon has capability -- would be a big win but are not common for this use case. Most binary wire codecs are traditionally optimized for byte streams or, for some recent codec designs, integer streams. Vector length framing is a more complicated format but with integer factor gains in efficiency for many implementations.
> That is just off the top of my head at the moment.
More information about the FoRK