物联网请求响应协议
我们需要构建一个可以与运行Android变体的嵌入式设备进行通信的服务器。 我们需要能够向设备发送命令并接收响应。 一个简单的命令可能会询问设备的状态。 我们不会有HTTP，所以我们需要客户端/设备与服务器建立连接。
我们正在考虑使用MQTT，因为它具有许多很好的属性（QoS，轻量级，为IoT构建），但它本身不支持请求响应工作流。
我们已经考虑在MQTT之上构建RPC，但在此之前，我只是想要人们对此事进行思考。 Websockets，WAMP，ZeroMQ会是更好的方法吗？
编辑：
Q1:我们是否需要RPC？
Q2:有没有办法构建系统，我总是发送异步类型的消息，并仍然提供良好的用户体验？
Q3:例子？
寻找实施示例，并体验构建超越单个设备的玩具示例的物联网通信系统的经验。
“ 一刀切 ”可能听起来像T恤衫的“聪明”口号
但为事后的尝试造成噩梦
修复设计不佳的架构
一旦真实世界的实现规模扩大
“ 合理精简 ”和“M inimum- V iable- P产品为准”的策略刚好足够的设计有更好的生存机会物联网规模和降低成本-的适应接受的（以最近VW全球设备只是天秤固件更新预计将对匈牙利和前捷克斯洛伐克地区的德国和汽车供应链造成约-2.5％至-3.0％的国内生产总值不利影响 - 是的， IoT领域的重要成本不仅仅是微不足道的美元） 。
物联网领域特定体系结构的智能工具是必须的
首先应该牢记的事实是， 物联网领域与传统传统计算架构的规模相差几个数量级。 最小化的本地资源（通过设计，上面也提到），具有不受控制的并发的大规模/计数， 真正并行性的巨大同步复杂性 （如果需要此类系统设计），请参阅： PARALLEL / PARALLEL CONCURRENT SEQUENTIAL消歧链接。
因此，在这种给定的状态下，需要正确选择工具。
虽然AMQP和其他power-MQ工具非常适合基于代理的设计（如果设计良好，中央MQ代理不必是单点故障，并且仍然“仅仅”是性能瓶颈），但是具有物联网设备的架构的开销要仔细验证，不管是否可行。
无代理ZeroCopy，ZeroSharing，ZeroBlocking，ZeroLatency（...几乎）
尽管AMQP已经为知名的ZeroMQ的无券商权力打开了大门，但同样的事情发生在Martin SUSTRIK重新定义规则并nanomsg又nanomsg 。
nanomsg ，除了便携性和轻量级，或者恰到好处的权重本身，它们已经成为IoT合作模式的理想选择，让您的项目远远超过所需的REQ / REP - 更多高级行为，就像SURVEY要求的那样，都是投票 
BUS分散路由 
或PIPE一个定向的单向管道在大规模传感网络中的分布式过程组合中特别有吸引力，并且是一个可爱的例子
特设问题解答：
A1:是的，如果设计体系结构要求， RPC可能使用相同的统一信令框架（而不是重新发明轮子或仅为Remote Proceducer Call添加另一个分布式层
A2:是的， ZeroMQ和Martin SUSTRIK的类似无代理几乎零延迟nanomsg框架非常适合进程间消息/信令服务。 您的顶级设计决定了这些权力是否能够被利用在任何接近它们（非常大的）充分潜力的地方，或浪费在表现不佳的使用模式上。 为了了解它们的限制，FOREX事件流以小于微秒的分辨率时间戳执行虚假事件。 在那里，你确实需要一个强大的框架（用于处理这样的爆炸）， 快速 （不会增加不必要的延迟），弹性线性可缩放 （内部能力可根据需求处理多重折叠）。 通过亲身体验，我可以证实，我自己的团队的创造力（虽然得到高度赞赏和实地测试，并在列表中获得了数十年的成功项目成果）， nanomsg是用户体验的限制因素 ，而不是ZeroMQ / nanomsg智能框架。
A3:是的，对于远程（负载平衡）中央日志记录（软实时最小延迟驱动，卸载分布式代理），已经使用ZeroMQ （DLL / LIB适配当前正在进行nanomsg端口）的nanomsg '能力）。 除非您的系统跨越太空（往返时间很容易在几分钟内完成）， 这种modus operandi既巧妙又 贴近“恰到好处”的设计理念。
根据您对物联网轻量化请求/响应协议的要求，CoAP（http://coap.technology/），IETF标准可能会有用。 它重量轻，您可以在其上构建RESTful服务。
另一个值得考虑的事情是服务器的“数据模型”和“服务接口”。 选择基于标准的通信协议（如HTTP，MQTT，CoAP）很重要，但选择基于标准的可互操作传感器数据模型和接口可能同样重要，以便您的应用程序可以互操作并且不需要担心它很快就会过时。 Open Geospatial Consortium（OGC）SensorThings API（http://ogc-iot.github.io/ogc-iot-api/）可能是一个可供选择的考虑因素。 它是一个开放标准，它的数据模型是基于ISO 19156观测和测量。
如果您的要求之一是请求/响应模式，我可以建议使用AMQP 。 AMQP协议通过请求结束响应之间的“关联”机制，本地支持这种模式。 在您的环境中，您可以尝试使用C语言中最终所有可用语言绑定（如基于Android的系统）的Apache Qpid Proton。