前言
本篇是MQTT-SN 1.2协议最后一篇翻译了,主要涉及实现要点,很简短。
需要支持QoS 值为 -1
QoS虽默认设置有0,1,2三个值,但还有一种情况其值为-1。来自客户端的PUBLISH消息中若QoS为-1的情况下,此刻客户端不会关心和网关有没有建立连接,也不在乎时间点,有消息就需要发出去。透明的网关需要维护此类消息并与远程的MQTT Server建立一个专用TCP连接。聚合网关或hybird混杂网关可使用已有的MQTT Server连接转发此类消息。
定时器和计时器实践建议
定时器/计数器 | 说明 | 推荐值 |
---|---|---|
T_ADV | 广播频率 | 大于15分钟 |
N_ADV | 没有接收到ADVERSE广播次数 | 2-3次 |
T_SEARCHGW | 发送SEARCHGW延迟 | 5秒 |
T_GWINFO | 等待网关响应GWINFO广播延迟时长 | 5秒 |
T_WAIT | 等待时长 | 大于5分钟 |
T_RETRY | 重试时长 | 10s - 15s |
N_RETRY | 重试次数 | 3-5次 |
网关处理客户端的休眠和存活定时器,需要根据客户端在所发送消息中延续时间的定义值。例如,定时器值应该高出10%大于指定值持续时间1分钟,如果不高出50%。
网关持有的Topic Id和Topic Name的映射维护
协议严重建议所有客户端的Topic Id和Topic Name之间对应关系不应该使用一个共享池对象,因为这样可以避免不同客户端Topic Id和Topic Name匹配错误,将PUBLISH消息发错地方(客户端接收者),可能会导致引发潜在的不可恢复的灾难性后果。
正确做法是按照客户端的维度为维护Topic Id和Topic Name的对应关系。任何两个客户端之间可能会存在同样的Topic Name,但对应的Topic Id不一样。可能Topic Id一致,但Topic Name不一样。
ZigBee 相关问题
- 在ZigBee规范中,网关需要被托管在一个协调器节点内,MQTT-SN协议建议网关更应该而驻留在一个不间断运行的的ZigBee路由器节点上,能够随时接收来自客户端消息。
- 受限于ZigBee网络支持层有限的数据负载容量,MQTT-SN消息最大负载被限制为60字节。
小结
MQTT-SN 1.2协议到此翻译(非直译)完毕,嗯,有种想要吐血的感觉,但也是坚持了下来 (^_^)。