[FoRK] PubSub NG Re: MQTT : Exploring the Protocols of IoT - News - SparkFun Electronics

J. Andrew Rogers andrew at jarbox.org
Fri Feb 27 11:11:38 PST 2015


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

-a


More information about the FoRK mailing list