前言
本篇是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)有沒有建立連接，也不在乎時(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 | 沒有接收到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é)。
小結(jié)
MQTT-SN 1.2協(xié)議到此翻譯（非直譯）完畢，嗯，有種想要吐血的感覺，但也是堅(jiān)持了下來(lái) (^_^)。
我的生涯一片無(wú)悔，我想起那天夕陽(yáng)下的奔跑，那是我逝去的青春。
---《萬(wàn)萬(wàn)沒想到》王大錘