前言

本篇是MQTT-SN 1.2協(xié)議最后一篇翻譯了，主要涉及實(shí)現(xiàn)要點(diǎn)，很簡(jiǎn)短。

需要支持QoS 值為 -1

QoS雖默認(rèn)設(shè)置有0,1,2三個(gè)值，但還有一種情況其值為-1。來(lái)自客戶端的PUBLISH消息中若QoS為-1的情況下，此刻客戶端不會(huì)關(guān)心和網(wǎng)關(guān)有沒(méi)有建立連接，也不在乎時(shí)間點(diǎn)，有消息就需要發(fā)出去。透明的網(wǎng)關(guān)需要維護(hù)此類消息并與遠(yuǎn)程的MQTT Server建立一個(gè)專用TCP連接。聚合網(wǎng)關(guān)或hybird混雜網(wǎng)關(guān)可使用已有的MQTT Server連接轉(zhuǎn)發(fā)此類消息。

定時(shí)器和計(jì)時(shí)器實(shí)踐建議

定時(shí)器/計(jì)數(shù)器說(shuō)明推薦值

T_ADV	廣播頻率	大于15分鐘
N_ADV	沒(méi)有接收到ADVERSE廣播次數(shù)	2-3次
T_SEARCHGW	發(fā)送SEARCHGW延遲	5秒
T_GWINFO	等待網(wǎng)關(guān)響應(yīng)GWINFO廣播延遲時(shí)長(zhǎng)	5秒
T_WAIT	等待時(shí)長(zhǎng)	大于5分鐘
T_RETRY	重試時(shí)長(zhǎng)	10s - 15s
N_RETRY	重試次數(shù)	3-5次

網(wǎng)關(guān)處理客戶端的休眠和存活定時(shí)器，需要根據(jù)客戶端在所發(fā)送消息中延續(xù)時(shí)間的定義值。例如，定時(shí)器值應(yīng)該高出10%大于指定值持續(xù)時(shí)間1分鐘，如果不高出50%。

網(wǎng)關(guān)持有的Topic Id和Topic Name的映射維護(hù)

協(xié)議嚴(yán)重建議所有客戶端的Topic Id和Topic Name之間對(duì)應(yīng)關(guān)系不應(yīng)該使用一個(gè)共享池對(duì)象，因?yàn)檫@樣可以避免不同客戶端Topic Id和Topic Name匹配錯(cuò)誤，將PUBLISH消息發(fā)錯(cuò)地方（客戶端接收者），可能會(huì)導(dǎo)致引發(fā)潛在的不可恢復(fù)的災(zāi)難性后果。

正確做法是按照客戶端的維度為維護(hù)Topic Id和Topic Name的對(duì)應(yīng)關(guān)系。任何兩個(gè)客戶端之間可能會(huì)存在同樣的Topic Name，但對(duì)應(yīng)的Topic Id不一樣。可能Topic Id一致，但Topic Name不一樣。

ZigBee 相關(guān)問(wèn)題

• 在ZigBee規(guī)范中，網(wǎng)關(guān)需要被托管在一個(gè)協(xié)調(diào)器節(jié)點(diǎn)內(nèi)，MQTT-SN協(xié)議建議網(wǎng)關(guān)更應(yīng)該而駐留在一個(gè)不間斷運(yùn)行的的ZigBee路由器節(jié)點(diǎn)上，能夠隨時(shí)接收來(lái)自客戶端消息。
• 受限于ZigBee網(wǎng)絡(luò)支持層有限的數(shù)據(jù)負(fù)載容量，MQTT-SN消息最大負(fù)載被限制為60字節(jié)。

轉(zhuǎn)載于:https://www.cnblogs.com/yudar/p/4642485.html

總結(jié)

以上是生活随笔為你收集整理的MQTT-SN协议乱翻之实现要点的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。