MQTT not IoT “god protocol,” but getting closer

lyzhangxiang

MQTT not IoT “god protocol,” but getting closer [复制链接]

有一种协议及其相关内容将万维网推向了成功，这就是 IP，或者叫做互联网协议。这个协议是每种浏览器与互联网连接的基础，也构成了 IT 数据中心的主干。有人认为物联网也会走同样的发展道路，他们相信拥有一个 IP 地址就足以让物联网连接在一起了。

但是物联网的问题不在 IP 上，而是叠加在 IP 之上的所有其他内容。运行诸如 HTTP、SSL 和 XML 这样的协议需要具备强大的计算能力和存储空间，目前一般的 PC、智能手机或者平板电脑等设备都已经完全胜任这一任务了，但是对于运行在一个很小的微控制器上的普通传感器来说这就有点勉为其难了(尽管 ARM Cortex-M7 的功能也很强大)。

为了解决这一难题，相关各方已经推出了大批的替代方案，大部分都是不具备互操作性的物联网协议，例如：6LoWPAN、AllJoyn、AMQP、ANT+、Bluetooth、CoAP、DASH7、DDS、INSTEON、KNX、MQTT、NFC、RFID、STOMP、Thread、Weightless、XMPP、ZigBee、以及 Z-Wave 等。这还只是其中的一部分，而且每周都会有具有更多思路的协议推出。

试图找到一种物联网的“圣典协议”，找到一种一统天下的端到端协议以便能够服务所有物品的想法是愚蠢的。一方面，传感器在范围、射频频谱、安全水平、拓扑结构、功率消耗等方面的要求是各不相同的，另外一方面，任何一个成功的物联网策略最终都需要与一个基于 IP 的云通过某种形式整合在一起。除此之外几乎很难找到其他类型的解决方案。因此物联网应用必须能够相互连接和交换数据。

解决方法是在传感器和致动器、移动设备、以及云之间搭建一个多重协议的桥梁，最好是开放式源代码，具有可扩展性，能够将大范围内的海量设备都包括进来。此外，传输应该是可靠的，能够经受住无线连接短暂的间断。

越来越多的机构正在将 MQTT 视为这一桥梁的一个组成部分。MQTT 既有完全高级版可以在 TCP/IP 上运行，也有简化版 MQTT-SN 用于非 IP 设备。其发布/订阅模式能够在让拓扑结构进行扩展的同时保留实时的特性以及服务质量的可配置性。

IBM 公司最初开发 MQTT 的目的是将其作为主机和服务器的消息传输代理，可整合入 WebSphere 为网络提供服务。随后公司在提供给 OASIS 以及 Eclipse 基金会时将其开放用于嵌入式用途。

IBM Bluemix 的一个重要部分是其 IoT Foundation 服务，这是一项基于云的 MQTT 实例，带有预定义的主题结构和消息格式。移动应用程序也早就开始使用 MQTT 了，如 Facebook Messenger 和 Salesforce.com 等。IBM 公司还有一个在 MQTT 基础上的 e-book 移动应用。

需要考虑的其他一些新进展包括：
· ARM 的 mbed device server 正在寻求用专门针对物联网的服务器来替代通用型网络服务器。借助于收购 Sensinode 公司而获得的技术，ARM 已经将HTTP、CoAP、以及 MQTT 整合在了一个平台上。
· 2lemetry 在此基础上通过 ThingFabric 的推出又向前迈了一步，将一些主要协议如 MQTT、CoAP、和 STOMP 连同可扩展性整合在了一起。
· PubNub 将一种 websocket 连接方式运行在 MQTT 上，重点实现云实施的低延迟和交付的可靠性。在 Atmel 公司的 Bits & Pieces 博客上有一篇访客写的很好的文章就是介绍 PubNub 的这一方法的。
· 说到 Atmel 和 Arduino，IBM 公司针对如何通过 IoT Foundation 充分发挥 Arduino 的作用提供了几种方法，例如一个 Arduino Uno 连接实例，以及一个如何实施云就绪温度传感器的系列说明。
· 开放源代码使许多人都深受鼓舞，不断出现各种独特的研究项目，其中一个比较令人感兴趣的项目是 AllJoyn 与 MQTT 之间的桥接。如果这个项目能够成功的话，其意义将是非常重要的，例如可以借助这种方式从一个移动设备上的 Facebook 直接控制家中的娱乐设施。

还是那句话，我不相信有一个“圣典协议”能够一劳永逸地在整个物联网上普遍采用，而且能够满足每一种具体应用的实际需求。最后脱颖而出的解决方案一定是将多个协议整合在一起用来为尽可能广泛的应用提供服务。MQTT 以实时方式将传感器和移动设备连接到大数据系统的能力正在吸引越来越多的人参与进来。

原文来至atmel官方blog

MQTT_V3.1_Protocol_Specific.pdf (977.27 KB, 下载次数: 25)

2015-1-15 13:14 上传

点击文件名下载附件

MQTT_V3.1_Protocol_Specific.pdf (977.27 KB, 下载次数: 25)

2015-1-15 13:14 上传

点击文件名下载附件

lyzhangxiang

MQTT协议简记
MQTT - MQ Telemetry Transport

• 轻量级的 machine-to-machine 通信协议。
• publish/subscribe模式。
• 基于TCP/IP。
• 支持QoS。
• 适合于低带宽、不可靠连接、嵌入式设备、CPU内存资源紧张。
• 是一种比较不错的Android消息推送方案。
• FacebookMessenger采用了MQTT。
• MQTT有可能成为物联网的重要协议。
  

消息体
file:///C:/Users/cacard/AppData/Local/Temp/enhtmlclip/Image.png



MessageType

file:///C:/Users/cacard/AppData/Local/Temp/enhtmlclip/Image(1).png

CONNECT
TCP连接建立完毕后，Client向Server发出一个Request。
如果一段时间内接收不到Server的Response，则关闭socket，重新建立一个session连接。
如果一个ClientID已经与服务器连接，则持有同样ClientID的旧有连接必须由服务器关闭后，新建立才能建立。

CONNACK
Server发出Response响应。
0x00 Connection Accepted
0x01 Connection Refused: unacceptable protocol version
0x02 Connection Refused: identifier rejected
0x03 Connection Refused: server unavailable
0x04 Connection Refused: bad user name or password
0x05 Connection Refused: not authorized

PUBLISH 发布消息
Client/Servier均可以进行PUBLISH。
publish message 应该包含一个TopicName(Subject/Channel)，即订阅关键词。

关于Topic通配符
/：用来表示层次，比如a/b，a/b/c。
#：表示匹配>=0个层次，比如a/#就匹配a/，a/b，a/b/c。
单独的一个#表示匹配所有。
不允许 a#和a/#/c。
+：表示匹配一个层次，例如a/+匹配a/b，a/c，不匹配a/b/c。
单独的一个+是允许的，a+不允许，a/+/b不允许

PUBACK 发布消息后的确认
QoS=1时，Server向Client发布该确认（Client收到确认后删除），订阅者向Server发布确认。

PUBREC / PUBREL / PUBCOMP
QoS=2时
1. Server->Client发布PUBREC（已收到）；
2. Client->Server发布PUBREL（已释放）；
3. Server->Client发布PUBCOMP（已完成），Client删除msg；
订阅者也会向Server发布类似过程确认。

PINGREQ / PINGRES 心跳
Client有责任发送KeepAliveTime时长告诉给Server。在一个时长内，发送PINGREQ，Server发送PINGRES确认。
Server在1.5个时长内未收到PINGREQ，就断开连接。
Client在1个时长内未收到PINGRES，断开连接。
一般来说，时长设置为几个分钟。最大18hours，0表示一直未断开。


QoS
file:///C:/Users/cacard/AppData/Local/Temp/enhtmlclip/Image(2).png


QoS=0：最多一次，有可能重复或丢失。

QoS=1：至少一次，有可能重复。
Client[Qos=1,DUP=0/*重复次数*/,MessageId=x] --->PUBLISH--> Server收到后，存储Message，发布，删除，向Client回发PUBACK
Client收到PUBACK后，删除Message；如果未收到PUBACK，设置DUP++，重新发送，Server端重新发布，所以有可能重复发送消息。

QoS=2：只有一次，确保消息只到达一次（用于比较严格的计费系统）。


Clean Session
如果为false(flag=0)，Client断开连接后，Server应该保存Client的订阅信息。
如果为true(flag=1)，表示Server应该立刻丢弃任何会话状态信息。



Refshttp://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html

freebsder

谢谢分享咨询

kemasz

过来看看~~~~~~~~~~~

dcexpert

楼主翻译的吗？厉害。