MQTT-SN协议乱翻之小结篇

2023-08-23 23:34:04

前言

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

MQTT-SN VS MQTT

MQTT-SN基于MQTT原有语义，但做了很多的调整。比如： 一个CONNECT消息被拆分为3个消息 主题名称需要使用主题标识符替代 * 网关地址可以广播、查询得知

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

比较类型	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属性决定：

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常用流程进行的流程简单梳理：

              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

码农公寓

前言