专业IM即时通讯软件开发,值得信赖!

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

MQTT 云聊IM 902℃

前言

本篇是MQTT-SN 1.2协议最后一篇翻译了,主要涉及实现要点,很简短。

需要支持QoS 值为 -1

QoS虽默认设置有0,1,2三个值,但还有一种情况其值为-1。来自客户端的PUBLISH消息中若QoS为-1的情况下,此刻客户端不会关心和网关有没有建立连接,也不在乎时间点,有消息就需要发出去。透明的网关需要维护此类消息并与远程的MQTT Server建立一个专用TCP连接。聚合网关或hybird混杂网关可使用已有的MQTT Server连接转发此类消息。

定时器和计时器实践建议

网关处理客户端的休眠和存活定时器,需要根据客户端在所发送消息中延续时间的定义值。例如,定时器值应该高出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 相关问题

  1. 在ZigBee规范中,网关需要被托管在一个协调器节点内,MQTT-SN协议建议网关更应该而驻留在一个不间断运行的的ZigBee路由器节点上,能够随时接收来自客户端消息。
  2. 受限于ZigBee网络支持层有限的数据负载容量,MQTT-SN消息最大负载被限制为60字节。

小结

MQTT-SN 1.2协议到此翻译(非直译)完毕,嗯,有种想要吐血的感觉,但也是坚持了下来 (^_^)。

我的生涯一片无悔,我想起那天夕阳下的奔跑,那是我逝去的青春。
—《万万没想到》王大锤

原文链接:http://www.blogjava.net/yongboy/archive/2015/01/11/422172.html

版权声明:部分文章、图片等内容为用户发布或互联网整理而来,仅供学习参考。如有侵犯您的版权,请联系我们,将立刻删除。
喜欢 (1)
仿微信聊天软件开发
点击这里给我发消息