MQTT-SN协议乱翻之小结篇

时间 2019-11-19

标签 mqtt 协议乱翻小结繁體版

原文原文链接

前言

这里简单作一些小结和对比，针对前面的协议翻译部分，一阶段的学习完结。html

MQTT-SN VS MQTT

MQTT-SN基于MQTT原有语义，但作了不少的调整。好比： 一个CONNECT消息被拆分为3个消息 主题名称须要使用主题标识符替代 * 网关地址能够广播、查询得知java

MQTT-SN 与 MQTT对比，使用一张图介绍git

比较类型	MQTT	MQTT-SN
传输类型	可靠点对点流模式	不可靠的数据报
通讯方式	TCP/IP	Non-IP 或 UDP
网络传输	Ethernet, WiFi, 3G	ZigBee，Bluetooth，RF
最小消息	2个字节	2个字节
最大消息	≤24MB	< 128个字节
电池供电	X	√
休眠支持	X	√
QoS -1(哑客户端)	X	√
主题标识符	X	√
网关自动发现和回退	X	√

QoS

有关QoS，MQTT-SN新增增长了哑客户端（QoS ：-1）支持：后端

QoS Level	消息传输次数	传输语义	传输保证
-1	≤ 1	至多一次	无链接，只用于传输，尽力而为，无保证；只有MQTT-SN支持
0	≤ 1	至多一次	尽力而为，无保证
1	≥ 1	至少一次	保证送达，可能存在重复
-1	≡ 1	只有一次	保证送达，而且不存在重复

网关的查询和发现

MQTT-SN客户端无须提早知道网关地址，接收网关的周期性广播好了，或直接广播一条网关查询；接收广播+主动查询，就够了
MQTT-SN对客户端/网关的乱入和丢失，处理的很好，备用网关在主网关挂掉以后便可转换为主网关，针对客户端而言，直接更新一个新的网关地址就能够
存在的若干网关能够互相协调彼此之间角色，互为主备stand-by，出现问题，主机下线维护，从机升级主机

清理会话

和MQTT 3.1协议相似，在上一次的客户端成功链接时在CONNECT中设置了清理会话标志clean session为false，遗嘱特性Will也为true，再次链接时，那么服务器为其缓存订阅数据和遗嘱数据是否已经被删除，对客户端不透明，由于就算是服务器因内存压力等清理了缓存，但没有通知到客户端，会形成订阅、遗嘱的误解。缓存

还好，MQTT-SN协议中，网关在清理掉遗嘱数据后，能够咨询客户端，或主动通知客户端断开，从新创建会话流程。服务器

在MQTT 3.1.1协议中，服务器会在CONNACK中标记会话是否已经被持久的标记。网络

主题标识符（Topic id）

确切来讲，MQTT-SN协议存在三种格式主题名称（topic name），可由消息标志位包含TopicIdType属性决定：session

0b01：预分配的主题标识符（topic id），16位天然数，0-65535范围
0b10：预分配的短主题名称（short topic name），只有两个字符表示
0b00：正常主题名称（topic name），可直接附加在REGISTER/SUBSCRIBE/WILLTOPICUPD消息对应字段中

全部主题被替换成标识符，在发布PUBLISH消息时，直接使用被指定的主题标识符topic id、short topic name便可。架构

MQTT-SN流程梳理

下面对MQTT-SN经常使用流程进行的流程简单梳理：eclipse

Client              Gateway            Server/Broker
                |                   |                    |
Generic Process | --- SERCHGW ----> |                    |
                | <-- GWINFO  ----- |                    |
                | --- CONNECT ----> |                    |
                | <--WILLTOPICREQ-- |                    |
                | --- WILLTOPIC --> |                    |
                | <-- WILLMSGREQ -- |                    |
                | --- WILLMSG ----> | ---- CONNECT ----> |(accepted)
                | <-- CONNACK ----- | <--- CONNACK ----- |
                | --- PUBLISH ----> |                    |
                | <-- PUBACK  ----- | (invalid TopicId)  |
                | --- REGISTER ---> |                    |
                | <-- REGACK  ----- |                    |
                | --- PUBLISH ----> | ---- PUBLISH ----> |(accepted)
                | <-- PUBACK  ----- | <---- PUBACK ----- |
                |                   |                    |
                //                  //                   //
                |                   |                    |
 SUBSCRIBE   -->| --- SUBSCRIBE --> | ---- SUBSCRIBE --> |
 [var Callback] | <-- SUBACK ------ | <--- SUBACK ------ |
                |                   |                    |
                //                  //                   //
                |                   |                    |
                | <-- REGISTER ---- | <--- PUBLISH ----- |<-- PUBLISH
                | --- REGACK  ----> |                    |
[exec Callback] | <-- PUBLISH  ---- |                    |
                | --- PUBACK   ---> | ---- PUBACK  ----> |--> PUBACK
                |                   |                    |
                //                  //                   //
                |                   |                    |
active -> asleep| --- DISCONNECT -> | (with duration)    |
                | <-- DISCONNECT -- | (without duration) |
                |                   |                    |
                //                  //                   //
                |                   |                    |
                |                   | <--- PUBLISH ----- |<-- PUBLISH
                |                   | ----- PUBACK ----> |
                |                   | <--- PUBLISH ----- |<-- PUBLISH
                |                   | ----- PUBACK ----> |
                |                   | (buffered messages)|
asleep -> awake |                   |                    |
                | --- PINGREQ ----> |                    |
awake state     | <-- PUBLISH  ---- |                    |
                | <-- PUBLISH  ---- |                    |
                | <-- PINGRESP ---- |                    |
asleep <-awake  |                   |                    |

MQTT-SN运行的协议栈

MQTT-SN能够运行在不一样的无线协议上，只要能够知足MQTT-SN 所定义便可：支持双向数据传输和网关便可，MQTT-SN彻底能够运行在其上面。

MQTT-SN能够在ZigBee、Bluetooth、RF、UDP、6loWPAN等底层协议层面运行。

MQTT-SN网络拓扑图

下面是来自网友的基于MQTT-SN运行的架构图：

但实际上的其网络拓扑可能更为复杂，好比两个不一样的传感器网络：

小结

传感器和制动器，合称为SA。传感器汇报状态数值（自身发布PUBLISH消息），制动器会被某参数值触发（接收到的PUBLISH消息）。比如，文件的输入-输出模式，传感器用于文件的读取，制动器用于文件写入。或者使用管道阀门，某指标超过阀值触发制动器报警，SA一块儿做用便于更好追踪数据。大部分时间，PUBLISH消息被用于触发制动器，这创建在后端服务器的分析结果基础上。

MQTT-SN比较知名的实现，好比(http://eclipse.org/proposals/technology.mosquitto/)[Eclipse Mosquitto]，(RMSB)[http://git.eclipse.org/c/mosquitto/org.eclipse.mosquitto.rsmb.git/]等，但不是实现全部已定义细节，好比MQTT-SN协议转发部分(MQTT-SN Forwarder)，就鲜有实现，但实现不难嘛，可能缺少相应的场景支持吧。

MQTT-SN支持相似于传感器的网关，稍强的网络可与适用于MQTT协议，这样看来，MQTT要作到链接一切（Connect anything），如IBM所发布的红皮书所说，要使用MQTT打造一个智能星球，有戏！

原文 http://www.blogjava.net/yongboy/archive/2015/01/13/422207.html