物联网请求响应协议

Question

我们需要构建一个可以与运行Android变体的某些嵌入式设备进行通信的服务器。我们需要能够向设备发送命令，并接收响应。一个简单的命令可能是询问设备的状态。我们不会有HTTP，所以我们需要让客户端/设备与服务器建立连接。

我们正在考虑使用MQTT，因为它具有许多不错的属性（QoS，轻量级，为物联网构建），但它本身不支持请求响应工作流。

我们已经考虑过在MQTT之上构建RPC，但在此之前，我只是想让人们对此问题有所了解。 Websockets，WAMP，ZeroMQ会更好吗？

修改

Q1: 我们甚至需要RPC吗？

Q2: 是否有建立系统的方法，我总是发送异步类型的消息并仍能提供良好的用户体验？

Q3: 任何示例？

寻找实施示例并亲身体验使用单个设备构建物联网通信系统的经验。

Answer 1

^{“一刀切”可能听起来像T恤衫的“智能”口号但却导致前噩梦-post尝试用于修复设计不良的架构，一旦实际实施规模扩大}
_{“正确选择”和“ M inimum- V iable- P 产品“足够设计的战略有更好的机会来实现物联网规模并保持<强>适应成本可接受（仅考虑最近大众全球设备固件更新的规模，预计会有 - 对匈牙利和前捷克斯洛伐克地区的德国和汽车供应链造成2.5％至-3.0％的GDP不利影响 - 是的，IoT领域的问题不仅仅是微不足道的数量 。）<子>}

IoT域特定架构的智能工具是必须的

应该首先考虑的事实是， IoT域与传统的传统计算架构的规模相差几个数量级。最小化本地资源（按设计，也在上面提到），大规模/计数与不受控制的并发，true parallelism ( if such system design is needed ), ref.: a PARALLEL v/s CONCURRENT SEQUENTIAL Disambiguation Link的巨大同步复杂性。

因此，在给定状态下，需要正确选择工具。

虽然 AMQP 和其他power-MQ工具非常适合基于代理（如果设计良好，中央MQ代理不需要单点故障而且仍然存在“只是”性能瓶颈）无论是否可行，都要仔细验证具有物联网设备的架构的开销。

无经纪人的ZeroCopy，ZeroSharing，ZeroBlocking，ZeroLatency _{（...几乎）}

虽然AMQP已为众所周知的 ZeroMQ 的无经纪人权力打开了大门，但当Martin SUSTRIK重新定义规则并带有 {时，这又发生了又一步。 {1}}

nanomsg，除了它的便携性和轻量级或恰到好处的正确权重之外，它本身也是一个很好的候选者，可以用于 nanomsg 模型操作，为您的项目提供的内容远远超过要求的 IoT / REQ - 更高级的行为，同样 REP _{一个人要求，所有投票} SURVEY _分散路由
或 BUS _{定向的单向管道}在大规模分布式流程组合中特别有吸引力感觉网络和一个可爱的例子

临时补充问题的答案：

PIPE 是的，如果设计架构需要，A1:可能使用相同的统一信令框架（不是重新发明轮子或仅为{添加另一个分布式层） {1}}

RPC 是的，来自Martin SUSTRIK的Remote Proceducer Call和类似的无代理几乎零延迟A2:框架非常适合进程间消息传递/信令服务。 您的顶级设计决定，这些权力是否会被利用到接近其^{（非常大的）}的全部潜力或浪费在表现不佳的使用模式上。为了了解它们的限制，FOREX事件流以低于微秒的分辨率时间戳执行事件的虚假爆炸。那里你真的需要一个框架，即 健壮 _{（处理此类爆炸）}， 快速 < / kbd>（不添加不必要的延迟），弹性 线性可扩展 （具有内部功能，可按需处理负载均衡）。经过实践经验，我可以确认我自己的团队的创造力（虽然高度赞赏和现场测试，在列表上有数十年的成功项目成就）是非常有限的因素用户体验，而不是ZeroMQ / nanomsg智能框架。

ZeroMQ 是的，几年来已经使用nanomsg（目前正在进行A3:端口的DLL / LIB适应）远程（负载均衡）中央记录（软实时最小延迟驱动，卸载分布式代理的功能）。除非你的系统跨度增长到太空（往返延迟很容易在几分钟 - 几小时）这个ZeroMQ 是智能＆amp; 接近“恰到好处”的设计理念。

Answer 2

根据您对物联网轻量级请求/响应协议的要求，IETF标准的CoAP（http://coap.technology/）可能很有用。它重量轻，你可以在它上面构建RESTful服务。

值得考虑的另一件事是＆＃34;数据模型＆＃34;和＆＃34;服务接口＆＃34;为您的服务器。选择基于标准的通信协议（如HTTP，MQTT，CoAP）非常重要，但选择基于标准的可互操作传感器数据模型和接口可能同样重要，这样您的应用程序就可以互操作而且不会需要担心它很快就会过时。开放地理空间联盟（OGC）SensorThings API（http://ogc-iot.github.io/ogc-iot-api/）可能是一个需要考虑的选项。它是一个开放标准，它的数据模型基于ISO 19156观察和测量。

Answer 3

如果您的要求之一是请求/响应模式，我建议您使用 AMQP 。 AMQP协议本身支持这种模式，具有＆＃34;相关性＆＃34;请求结束响应之间的机制。 在您的环境中，您可以尝试在C中使用最终所有可用语言绑定的Apache Qpid Proton（对于基于Android的系统）。

Answer 4

对于那些已经使用MQTT通信并希望通过其服务获得请求/响应的人，您可以尝试 replyer （https://github.com/netbeast/replyer），这是一种针对MQTT数据包结构和协议的策略，而不是而不是一个新的。

Answer 5

我建议不要创建自己的协议，而是使用LoraWAN协议，该协议已包含那些加入/接受（与请求/响应相同）协议。

LoraWAN协议的

Here's spec - 第47页描述了join / accept。

Answer 6

基本上，rpc和消息传递在功能上是等价的，因为我相信在20世纪70年代剑桥的李约瑟教授正式证明了这一点。正如您所说，MQTT具有一些很好的传输属性，旨在帮助缩小占用空间，间歇连接的设备。

关于RPC的观点是，它支持同步的单线程编程风格。但是，如果您使用的是Android，那么您不太可能为UI同步等待RPC完成做好准备。因此，我个人认为，我发现使用直接消息传递系统（如MQTT）更容易，并且可以根据需要跟踪事务状态（状态机，状态变量等）。

至于基于MQTT的UI的非玩具示例，您可以查看我们的平台http://www.thingstud.io。使用MQTT，多个设备不是问题，因为UI甚至不知道它是与一个设备通信还是多个设备。

麦克

Answer 7

无法与其他协议对话，但MQTT确实有一些您可能想要查看的功能：

如果您只想弄清楚设备是否已连接，您可以使用名为'last will'的功能在超时或断开连接时发送预先确定的消息。使用它和Quality-of-service levels，你应该能够跟踪设备状态，知道你的消息是否被接收，然后监控设备的发布渠道以处理响应。

Answer 8

如果您只需要请求/响应协议，则可以使用CoAP（http://coap.technology/），它就像HTTP并具有HTTP动词支持。

MQTT属于pub-sub模型。理想的说，你需要第三台运行MQTT经纪人的机器。

Answer 9

在我看来，MQTT 最适合 IoT，我向您推荐 EMQ，它是 MQTT 服务器。

如果您的嵌入式设备以二进制形式传输数据，并且需要服务器根据协议对其进行解析，那么您可以使用FastProto(https://github.com/indunet/fastproto) 进行解码和编码。