MQTT-SN协议乱翻之实现要点

前言

本篇是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协议到此翻译（非直译）完毕，嗯，有种想要吐血的感觉，但也是坚持了下来 (^_^)。