IoT request response protocol

IoT request response protocol

"one-size-fits-all" may sound like a "smart" slogan for T-shirts
but causes nightmares for ex-post attempts
to fix poorly designed architectures
once real-world implementations scale

"right-sizing" and "Minimum-Viable-Product" strategies for just-enough designs have much better chance to survive IoT scales and to keep costs-of-adaptation acceptable ( take just the scales of the recent VW global device firmware update, expected to have about -2.5% to -3.0% GDP adverse impacts on Germany and automotive supply chains in Hungary and former Czechoslovakia regions - Yes, co$t$ matter in IoT domain more than just the trivial count$.)


A smart-fit tool for IoT domain-specific architecture is a must

The first thing that ought to be born in mind is the fact, that the IoT domain is by several orders of magnitude different from scales of the classical legacy computing architectures. Minimized local resources ( by design, also mentioned above ), massive scales/counts with uncontrolled concurrency, immense synchronization complications for true parallelism ( if such system design is needed ), ref.: a PARALLEL v/s CONCURRENT SEQUENTIAL Disambiguation Link.

Thus a proper selection of tools is needed in context with this given state.

While AMQP and other power-MQ tools are great for broker-based ( if well designed, the central MQ-broker need not be a single-point of failure & remains "just" a performance bottleneck ) the overheads for architectures with IoT-devices are to be carefully validated, whether feasible.

Broker-less ZeroCopy, ZeroSharing, ZeroBlocking, ZeroLatency(...almost)

A PIPELINE pattern While AMQP has opened doors for the broker-less powers of well known ZeroMQ, the same happened another step further when Martin SUSTRIK redefined the rules and came with nanomsg.

nanomsg, besides it's portability and light-weight-ness or a just enough right-weight-ness sets itself a good candidate ready for IoT models of co-operation, giving your Project much more than the asked REQ/REP where needed -- more advanced behaviours, alike SURVEY one asks, all voteA SURVEY pattern
BUSdecentralised routing
BUS- or PIPE a directed, one-way pipe are particularly attractive in distributed process compositions in massive sensoric networks and a lovely example


Answers for ad-hoc added Questions:

A1: Yes, if design architecture requires, RPC might be using the same uniform signalling framework ( not reinventing wheel or adding just-another-distributed layer just for Remote Proceducer Call

A2: Yes, ZeroMQ and similar broker-less almost Zero-Latency nanomsg framework from Martin SUSTRIK are a good fit for inter-process messaging/signalling services. Your top-level design decides, whether these powers get harnessed anywhere near to their (awfully magnific) full potential or wasted into underperforming usage-patterns. To have an idea of their limits, FOREX event-streams execute spurious blasts of event with less than microsecond resolution time-stamping. There you really need a framework, that is robust ( to handle such blasts ), fast ( not to add unnecessary delays ), elastically linear-scaleable ( with inner abilities to handle load-balancing on demand in many-folds ). After hands-on experience I can confirm that my own team's creativity ( while highly appreciated and field-tested with many decades of successfull project achievements on the list ) is the very limiting factor for user-experience, not the ZeroMQ / nanomsg smart-frameworks.

A3: Yes, for a few years already using ZeroMQ ( DLL/LIB-adaptations are currently in progress for a nanomsg port ) for remote (load-balanced) central logging ( soft-realtime minimum latency-motivated, off-loading of distributed agents' capabilities ). Unless your system span grows into space ( where round-trip latencies are easily in minutes-hours ) this modus operandi is both smart & close to "just-enough"-design ideals.