MQTT-SN協(xié)議亂翻之實(shí)現(xiàn)要點(diǎn)
前言
本篇是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)自客戶(hù)端的PUBLISH消息中若QoS為-1的情況下,此刻客戶(hù)端不會(huì)關(guān)心和網(wǎng)關(guān)有沒(méi)有建立連接,也不在乎時(shí)間點(diǎn),有消息就需要發(fā)出去。透明的網(wǎng)關(guān)需要維護(hù)此類(lèi)消息并與遠(yuǎn)程的MQTT Server建立一個(gè)專(zhuān)用TCP連接。聚合網(wǎng)關(guān)或hybird混雜網(wǎng)關(guān)可使用已有的MQTT Server連接轉(zhuǎn)發(fā)此類(lèi)消息。
定時(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)處理客戶(hù)端的休眠和存活定時(shí)器,需要根據(jù)客戶(hù)端在所發(fā)送消息中延續(xù)時(shí)間的定義值。例如,定時(shí)器值應(yīng)該高出10%大于指定值持續(xù)時(shí)間1分鐘,如果不高出50%。
網(wǎng)關(guān)持有的Topic Id和Topic Name的映射維護(hù)
協(xié)議嚴(yán)重建議所有客戶(hù)端的Topic Id和Topic Name之間對(duì)應(yīng)關(guān)系不應(yīng)該使用一個(gè)共享池對(duì)象,因?yàn)檫@樣可以避免不同客戶(hù)端Topic Id和Topic Name匹配錯(cuò)誤,將PUBLISH消息發(fā)錯(cuò)地方(客戶(hù)端接收者),可能會(huì)導(dǎo)致引發(fā)潛在的不可恢復(fù)的災(zāi)難性后果。
正確做法是按照客戶(hù)端的維度為維護(hù)Topic Id和Topic Name的對(duì)應(yīng)關(guān)系。任何兩個(gè)客戶(hù)端之間可能會(huì)存在同樣的Topic Name,但對(duì)應(yīng)的Topic Id不一樣??赡躎opic 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)自客戶(hù)端消息。
- 受限于ZigBee網(wǎng)絡(luò)支持層有限的數(shù)據(jù)負(fù)載容量,MQTT-SN消息最大負(fù)載被限制為60字節(jié)。
小結(jié)
MQTT-SN 1.2協(xié)議到此翻譯(非直譯)完畢,嗯,有種想要吐血的感覺(jué),但也是堅(jiān)持了下來(lái) (^_^)。
我的生涯一片無(wú)悔,我想起那天夕陽(yáng)下的奔跑,那是我逝去的青春。
---《萬(wàn)萬(wàn)沒(méi)想到》王大錘
posted on 2015-01-11 12:08 nieyong 閱讀(6510) 評(píng)論(1) 編輯 收藏 所屬分類(lèi): MQTT