前言
本篇是MQTT-SN 1.2協(xié)議最后一篇翻譯了，主要涉及實現(xiàn)要點，很簡短。
需要支持QoS 值為 -1
QoS雖默認設置有0,1,2三個值，但還有一種情況其值為-1。來自客戶端的PUBLISH消息中若QoS為-1的情況下，此刻客戶端不會關心和網(wǎng)關有沒有建立連接，也不在乎時間點，有消息就需要發(fā)出去。透明的網(wǎng)關需要維護此類消息并與遠程的MQTT Server建立一個專用TCP連接。聚合網(wǎng)關或hybird混雜網(wǎng)關可使用已有的MQTT Server連接轉(zhuǎn)發(fā)此類消息。
定時器和計時器實踐建議
| 定時器/計數(shù)器 | 說明 | 推薦值 |
| T_ADV | 廣播頻率 | 大于15分鐘 |
| N_ADV | 沒有接收到ADVERSE廣播次數(shù) | 2-3次 |
| T_SEARCHGW | 發(fā)送SEARCHGW延遲 | 5秒 |
| T_GWINFO | 等待網(wǎng)關響應GWINFO廣播延遲時長 | 5秒 |
| T_WAIT | 等待時長 | 大于5分鐘 |
| T_RETRY | 重試時長 | 10s - 15s |
| N_RETRY | 重試次數(shù) | 3-5次 |
網(wǎng)關處理客戶端的休眠和存活定時器，需要根據(jù)客戶端在所發(fā)送消息中延續(xù)時間的定義值。例如，定時器值應該高出10%大于指定值持續(xù)時間1分鐘，如果不高出50%。
網(wǎng)關持有的Topic Id和Topic Name的映射維護
協(xié)議嚴重建議所有客戶端的Topic Id和Topic Name之間對應關系不應該使用一個共享池對象，因為這樣可以避免不同客戶端Topic Id和Topic Name匹配錯誤，將PUBLISH消息發(fā)錯地方（客戶端接收者），可能會導致引發(fā)潛在的不可恢復的災難性后果。
正確做法是按照客戶端的維度為維護Topic Id和Topic Name的對應關系。任何兩個客戶端之間可能會存在同樣的Topic Name，但對應的Topic Id不一樣。可能Topic Id一致，但Topic Name不一樣。
ZigBee 相關問題
- 在ZigBee規(guī)范中，網(wǎng)關需要被托管在一個協(xié)調(diào)器節(jié)點內(nèi)，MQTT-SN協(xié)議建議網(wǎng)關更應該而駐留在一個不間斷運行的的ZigBee路由器節(jié)點上，能夠隨時接收來自客戶端消息。
- 受限于ZigBee網(wǎng)絡支持層有限的數(shù)據(jù)負載容量，MQTT-SN消息最大負載被限制為60字節(jié)。
小結(jié)
MQTT-SN 1.2協(xié)議到此翻譯（非直譯）完畢，嗯，有種想要吐血的感覺，但也是堅持了下來 (^_^)。
我的生涯一片無悔，我想起那天夕陽下的奔跑，那是我逝去的青春。
---《萬萬沒想到》王大錘