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字節。