物联网请求响应协议

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. 解决方案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 -- more advanced behaviours, alike SURVEY BUS or PIPE are particularly attractive in distributed process compositions in massive sensoric networks and a lovely exampleAnswers 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 CallA2: 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 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 , 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. 这篇关于物联网请求响应协议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！