物联网请求响应协议 [英] IoT request response protocol
问题描述
我们需要构建一个服务器，该服务器可以与运行Android变体的某些嵌入式设备进行通信.我们需要能够将命令发送到设备并接收响应.一个简单的命令可能是询问设备的状态.我们没有HTTP，因此我们需要让客户端/设备与服务器建立连接.
我们正在考虑使用MQTT，因为它具有很多不错的属性(QoS，轻量级，为IoT构建)，但是它本身不支持请求响应工作流.
我们已经考虑过在MQTT之上构建RPC，但是在此之前，我只是希望人们对此有想法. Websockets，WAMP，ZeroMQ是否会是更好的方法?
Q1: 我们甚至需要RPC吗?
Q2: 是否可以构建我总是发送异步类型消息并仍然提供良好用户体验的系统?
Q3: 有示例吗?
除了使用单个设备的玩具示例之外，还需要寻找实现示例并亲身体验构建IoT通信系统的经验.
"一个千篇一律的所有"听起来像是" smart " T恤的口号
，但事后尝试的噩梦
一旦实际实现的规模扩大，就无法修复设计欠佳的体系结构
"调整大小"和" M 最小- V 可靠- P 生成"足够多的设计策略具有更好的机会来承受IoT规模并保持适应成本(仅接受最近大众汽车全球设备固件更新的规模，预计约为-2.5 ％到-3.0％的GDP对德国以及匈牙利和前捷克斯洛伐克地区的汽车供应链的不利影响-是的，在IoT域中，总的美元价值比琐碎的数字更重要.)
物联网领域特定架构的智能适配工具是必不可少的
首先应该想到的事实是， IoT域与传统传统计算体系结构的规模相差几个数量级.最小化的本地资源(通过设计，也如上所述)，大规模/无控制的并发计数， 真正的并行性的巨大同步复杂性(如果需要这种系统设计)，请参考: PARALLEL v/s CONCURRENT SEQUENTIAL 消歧链接.
因此，需要在上下文中的工具适当地选择与该给定状态.
AMQP 和其他强大的MQ工具非常适合基于代理的(如果设计合理，则中央MQ-broker不必成为单点故障，并且保持只是性能瓶颈")是否可行，必须仔细验证具有IoT设备的架构的开销.
无经纪人的ZeroCopy，ZeroSharing，ZeroBlocking，ZeroLatency (...几乎)
尽管AMQP为知名的 ZeroMQ 的无经纪人权力打开了大门，但当Martin SUSTRIK重新定义规则并附带 nanomsg 时，这又发生了又一步strong>.
nanomsg，除了它的便携性和轻巧性，或者足够适中的权重本身，它为 IoT 合作模型做好了准备，可以为您提供比要求的 REQ / REP /strong> 一个问题，所有投票
BUS 去中心化路由
或 PIPE 定向单向管道在大规模传感网络中的分布式过程组成中特别有吸引力，例子
临时添加的问题的答案:
A1: 是，如果设计体系结构要求，RPC可能会使用相同的统一信号框架(不是为Remote Proceducer Call重新发明轮子或添加仅另一个分布的层
A2: 是的，Martin SUSTRIK的ZeroMQ和类似的没有经纪人的几乎零延迟的nanomsg框架非常适合进程间消息传递/信令服务. 您的顶级设计将决定，是将这些功能利用到它们的(非常强大)的全部潜力附近，还是浪费在性能不佳的使用模式上.为了了解其局限性，FOREX事件流以不到毫秒级的时间戳来执行事件的虚假爆发.在那里，您确实需要一个框架，它是 鲁棒 (用于处理此类爆炸)， 快速 (不添加不必要的延迟)，弹性地 linear-scaleable (具有按需处理多种负载平衡的内在能力).经过亲身实践，我可以确定我自己团队的创造力(尽管受到高度赞赏并经过数十年成功的项目成就现场测试)是限制用户体验的重要因素，而不是ZeroMQ/nanomsg智能框架.
A3: 是的，几年来已经使用ZeroMQ(当前正在对nanomsg端口进行DLL/LIB适配)用于远程(负载平衡)中央日志记录(由软实时最小延迟引起的分布式代理功能的卸载).除非您的系统跨度扩展到空间(往返延迟很容易在数分钟小时之内)，否则此modus operandi 既是 smart 接近足够"的设计理想.
We need to build a server that can communicate with some embedded devices running a variant of Android. We need to be able to send commands to the device, and receive a response. A simple command might be asking the device for it's status. We won't have HTTP, so we need to have the client/device establish a connection with the server.
We were considering using MQTT as it has a lot of nice properties (QoS, lightweight, built for IoT), but it doesn't natively support a request response workflow.
We have considered building RPC on top of MQTT, but before we do I just wanted peoples thoughts on the matter. Would Websockets, WAMP, ZeroMQ be a better approach?
Edit:
Q1: Do we even need RPC?
Q2: Is there an approach to building systems where I always send async type messages and still provide a good user experience?
Q3: Any examples?
Looking for implementation examples and hands on experience of building an IoT communication system beyond a toy example with a single device.
"one-size-fits-all" may sound as a "smart" slogan for T-shirts
but causes nightmare 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
A first thing that ought to be born in mind is the fact, that IoT domain is by several orders of magnitude different from scales of the classical legacy computing architectures. Minimised local-resources ( by design, also mentioned above ), massive scales/counts with uncontrolled concurrency, immense synchronisation 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)
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 voteBUSdecentralised routing
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.
这篇关于物联网请求响应协议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
