前言
這里簡單做一些小結和對比，針對前面的協議翻譯部分，一階段的學習完結。
MQTT-SN VS MQTT
MQTT-SN基于MQTT原有語義，但做了很多的調整。比如： 一個CONNECT消息被拆分為3個消息 主題名稱需要使用主題標識符替代 * 網關地址可以廣播、查詢得知
MQTT-SN 與 MQTT對比，使用一張圖介紹
| 比較類型 | MQTT | MQTT-SN |
| 傳輸類型 | 可靠點對點流模式 | 不可靠的數據報 |
| 通信方式 | TCP/IP | Non-IP 或 UDP |
| 網絡傳輸 | Ethernet, WiFi, 3G | ZigBee，Bluetooth，RF |
| 最小消息 | 2個字節 | 2個字節 |
| 最大消息 | ≤24MB | < 128個字節 |
| 電池供電 | X | √ |
| 休眠支持 | X | √ |
| QoS -1(啞客戶端) | X | √ |
| 主題標識符 | X | √ |
| 網關自動發現和回退 | X | √ |
QoS
有關QoS，MQTT-SN新增增加了啞客戶端（QoS ：-1）支持：
| QoS Level | 消息傳輸次數 | 傳輸語義 | 傳輸保證 |
| -1 | ≤ 1 | 至多一次 | 無連接，只用于傳輸，盡力而為，無保證；只有MQTT-SN支持 |
| 0 | ≤ 1 | 至多一次 | 盡力而為，無保證 |
| 1 | ≥ 1 | 至少一次 | 保證送達，可能存在重復 |
| -1 | ≡ 1 | 只有一次 | 保證送達，并且不存在重復 |
網關的查詢和發現
- MQTT-SN客戶端無須提前知道網關地址，接收網關的周期性廣播好了，或直接廣播一條網關查詢；接收廣播+主動查詢，就夠了
- MQTT-SN對客戶端/網關的亂入和丟失，處理的很好，備用網關在主網關掛掉之后即可轉換為主網關，針對客戶端而言，直接更新一個新的網關地址就可以
- 存在的若干網關可以互相協調彼此之間角色，互為主備stand-by，出現問題，主機下線維護，從機升級主機
清理會話
和MQTT 3.1協議類似，在上一次的客戶端成功連接時在CONNECT中設置了清理會話標志clean session為false，遺囑特性Will也為true，再次連接時，那么服務器為其緩存訂閱數據和遺囑數據是否已經被刪除，對客戶端不透明，因為就算是服務器因內存壓力等清理了緩存，但沒有通知到客戶端，會造成訂閱、遺囑的誤解。
還好，MQTT-SN協議中，網關在清理掉遺囑數據后，可以咨詢客戶端，或主動通知客戶端斷開，重新建立會話流程。
在MQTT 3.1.1協議中，服務器會在CONNACK中標記會話是否已經被持久的標記。
主題標識符（Topic id）
確切來說，MQTT-SN協議存在三種格式主題名稱（topic name），可由消息標志位包含TopicIdType屬性決定：
- 0b01：預分配的主題標識符（topic id），16位自然數，0-65535范圍
- 0b10：預分配的短主題名稱（short topic name），只有兩個字符表示
- 0b00：正常主題名稱（topic name），可直接附加在REGISTER/SUBSCRIBE/WILLTOPICUPD消息對應字段中
所有主題被替換成標識符，在發布PUBLISH消息時，直接使用被指定的主題標識符topic id、short topic name即可。
MQTT-SN流程梳理
下面對MQTT-SN常用流程進行的流程簡單梳理：
Client Gateway Server/Broker
| | |
Generic Process | --- SERCHGW ----> | |
| <-- GWINFO ----- | |
| --- CONNECT ----> | |
| <--WILLTOPICREQ-- | |
| --- WILLTOPIC --> | |
| <-- WILLMSGREQ -- | |
| --- WILLMSG ----> | ---- CONNECT ----> |(accepted)
| <-- CONNACK ----- | <--- CONNACK ----- |
| --- PUBLISH ----> | |
| <-- PUBACK ----- | (invalid TopicId) |
| --- REGISTER ---> | |
| <-- REGACK ----- | |
| --- PUBLISH ----> | ---- PUBLISH ----> |(accepted)
| <-- PUBACK ----- | <---- PUBACK ----- |
| | |
// // //
| | |
SUBSCRIBE -->| --- SUBSCRIBE --> | ---- SUBSCRIBE --> |
[var Callback] | <-- SUBACK ------ | <--- SUBACK ------ |
| | |
// // //
| | |
| <-- REGISTER ---- | <--- PUBLISH ----- |<-- PUBLISH
| --- REGACK ----> | |
[exec Callback] | <-- PUBLISH ---- | |
| --- PUBACK ---> | ---- PUBACK ----> |--> PUBACK
| | |
// // //
| | |
active -> asleep| --- DISCONNECT -> | (with duration) |
| <-- DISCONNECT -- | (without duration) |
| | |
// // //
| | |
| | <--- PUBLISH ----- |<-- PUBLISH
| | ----- PUBACK ----> |
| | <--- PUBLISH ----- |<-- PUBLISH
| | ----- PUBACK ----> |
| | (buffered messages)|
asleep -> awake | | |
| --- PINGREQ ----> | |
awake state | <-- PUBLISH ---- | |
| <-- PUBLISH ---- | |
| <-- PINGRESP ---- | |
asleep <-awake | | |
MQTT-SN運行的協議棧
MQTT-SN可以運行在不同的無線協議上，只要可以滿足MQTT-SN 所定義即可：支持雙向數據傳輸和網關即可，MQTT-SN完全可以運行在其上面。
MQTT-SN可以在ZigBee、Bluetooth、RF、UDP、6loWPAN等底層協議層面運行。
MQTT-SN網絡拓撲圖
下面是來自網友的基于MQTT-SN運行的架構圖：
但實際上的其網絡拓撲可能更為復雜，比如兩個不同的傳感器網絡：
小結
傳感器和制動器，合稱為SA。傳感器匯報狀態數值（自身發布PUBLISH消息），制動器會被某參數值觸發（接收到的PUBLISH消息）。好比，文件的輸入-輸出模式，傳感器用于文件的讀取，制動器用于文件寫入。或者使用管道閥門，某指標超過閥值觸發制動器報警，SA一起作用便于更好追蹤數據。大部分時間，PUBLISH消息被用于觸發制動器，這建立在后端服務器的分析結果基礎上。
MQTT-SN比較知名的實現，比如(http://eclipse.org/proposals/technology.mosquitto/)[Eclipse Mosquitto]，(RMSB)[http://git.eclipse.org/c/mosquitto/org.eclipse.mosquitto.rsmb.git/]等，但不是實現所有已定義細節，比如MQTT-SN協議轉發部分(MQTT-SN Forwarder)，就鮮有實現，但實現不難嘛，可能缺乏相應的場景支持吧。
MQTT-SN支持類似于傳感器的網關，稍強的網絡可與適用于MQTT協議，這樣看來，MQTT要做到連接一切（Connect anything），如IBM所發布的紅皮書所說，要使用MQTT打造一個智能星球，有戲！