聂永的博客

记录工作/学习的点点滴滴。

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

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



----------------------------------------------------------------------------
广而告之,让您自由畅游网络~
推荐一个我一直使用的VPN 翻*墙利器,平常正常谷歌搜索,登陆Gmail,闲时观看youtube等高清视频一点都不卡!
再超值提供一个近期2015年有效的9折优惠码:10off2015

作为码农,严重推荐!

posted on 2015-01-11 12:08 nieyong 阅读(5833) 评论(1)  编辑  收藏 所属分类: MQTT

评论

# re: MQTT-SN协议乱翻之实现要点[未登录] 2015-03-04 10:36 david

这个协议的具体实现,和应用设备有哪些?  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

所有文章皆为原创,若转载请标明出处,谢谢~

新浪微博,欢迎关注:

导航

<2015年1月>
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

统计

常用链接

留言簿(55)

随笔分类(125)

随笔档案(147)

个人收藏

最新随笔

搜索

最新评论

阅读排行榜

评论排行榜