前言
本篇是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字節。
小結
MQTT-SN 1.2協議到此翻譯（非直譯）完畢，嗯，有種想要吐血的感覺，但也是堅持了下來 (^_^)。
我的生涯一片無悔，我想起那天夕陽下的奔跑，那是我逝去的青春。
---《萬萬沒想到》王大錘