聶永的博客

前言

緊接著上篇初步介紹，本文為第二篇，主要梳理MQTT-SN 1.2協議中定義的消息格式。

通用消息格式

消息頭部

• 長度要么是1個字節，要么3個字節表示，并且自身也會包含在其內。一個字節可表示256長度，一般情況下，完全夠用了。
• 只需要判斷第一個字節是否為 0x01，若是那么長度為3個字節表示，剩下的兩個字節會表示真正的消息長度，最大長度為65535
• 否則長度就是一個字節表示，256個長度，大部分消息長度都是一個字節，除非特別提醒

備注：

 MQTT-SN不支持消息的分片和重組。底層網絡所定義數據包長度若小于MQTT-SN消息的最大長度，自身進行的分片和重組，對MQTT-SN協議本身不受影響。

MQTT-SN消息類型

MQTT-SN定義的消息類型數量眾多，超過25個，感覺有些頭大。

消息可變部分

可變字段很多，與MQTT相比，多了：

1. 持續時長字段（Duration）
2. 標識符Flags有所不同，下面表格進行說明
3. 網關地址（GwAdd），可變長度，但依賴于底層網絡，在ZigBee網絡中2個字節長度
4. 一個字節網關Id（GwId）
5. 協議Id（ProtocolId），一個字節，唯一值 0x01，統一表示協議名稱和協議名稱
6. 廣播路徑跳數(廣播路徑深度/廣播輻射范圍)，Radius，一個字節表示，0x00表示廣播給當前網絡中所有節點
7. CONNECT/REGISTER/SUBSCRIBE/PUBLISH等消息對應回執中都會包含返回碼Recode Code，見下表格

具體消息格式說明

ADVERTISE

網關周期性會對當前網絡下所有客戶端、節點進行廣播，用于客戶端發現可用網關。

SEARCHGW

客戶端主動尋找網關進行廣播的消息，廣播路徑范圍受限于當前網絡環境下的客戶端部署密度，比如只有1跳廣播在非常密集的網絡環境下客戶端都可以彼此互相訪問。

GWINFO

GWINFO作為對SEARCHGW消息的響應：

• 若由網關發出，則無GwAdd字段
• 若來自于客戶端，需要包含網關地址

CONNECT

客戶端向網關發出建立連接的消息。

在CONNECT消息標志位具體表示如下：

• 0/1 表示具體值待定
• X 表示沒有使用到

在Flags中使用到的標志位：

1. Will：若為1，客戶端會在稍后請求遺囑主題和遺囑消息
2. CleanSession：不但表示訂閱持久化，同時也被可擴展到遺囑主題和遺囑消息中

CONNACK

網關對客戶端發出CONNECT消息的響應。

WILLTOPICREQ

根據客戶端CONNECT標志位中WILL字段為true情況下，網關向客戶端發出遺囑主題請求，格式如下：

只有頭部部分，很簡單。

WILLTOPIC

客戶端作為網關WILLTOPICREQ請求響應消息。下面是一個正常版本的WILLTOPIC消息：

此時的標志位如下

而空的WILLTOPIC也是允許存在的，就兩個字節表示，用于客戶端請求刪除已存在于服務器端的對應遺囑主題和消息。

WILLMSGREQ

根據客戶端CONNECT標志位中WILL字段為真情況下，網關向客戶端發出遺囑消息請求，格式如下：

只有頭部部分，沒有別的。

WILLMSG

客戶端對網關WILLMSGREQ請求的響應，從而把遺囑消息傳遞給網關進行保存。

REGISTER

• 客戶端-->網關，請求主題（topic name）對應的主題標識符（topic id）
• 網關-->客戶端，通知主題（topic name）已經被指派到某個主題標識符（topic id）

REGACK

客戶端或網關針對REGISTER消息的響應。

PUBLISH

PUBLISH消息用于客戶端或網關發布消息用：

標識位具體如下：

標識位里面各個字段和MQTT協議一致，無須多解釋。

PUBACK

客戶端/網關僅僅對QoS 1/2的PUBLISH消息做出響應。

處理PUBLISH消息異常？在PUBACK消息中的ReturnCode字段中以相應值體現出來，這就要求接收者處理拒絕理由。

PUBREC, PUBREL, PUBCOMP

只有在PUBLISH消息中QoS 2時，PUBREC, PUBREL, PUBCOMP才會一起登場，否則是沒有出場機會的。消息格式嘛，都很統一：

SUBSCRIBE

SUBSCRIBE用于客戶端訂閱某個主題的消息。

標識位具體如下：

此處，標志位中TopicIdType決定了SUBSCRIBE消息中TopicId/TopicName字段具體填充值：預定義topic id，或短小兩個字符表示主題（topic name），或直接填寫主題。

SUBACK

網關->客戶端，訂閱處理情況的確認回執，接受訂閱或出于其它原因拒絕之。

標識位具體如下：

SUBACK消息標志位中QoS為網關根據實際情況授權后的QoS具體值，這也應該是客戶端需要知道并處理的。

UNSUBSCRIBE

UNSUBSCRIBE用于客戶端取消訂閱某個主題的消息。

標識位具體如下：

UNSUBSCRIBE消息標志位中唯一可用屬性TopicIdType決定了UNSUBSCRIBE消息中TopicId/TopicName字段具體填充值。

UNSUBACK

網關->客戶端，取消訂閱處理情況的確認回執，很簡單，4個字節表示。

PINGREQ

和MQTT協議中的PINGREQ一致，存活檢測。

PINGRESP

接受PINGREQ消息的一方，如網關響應PINGRESP消息表示自己現在運行OK。

另外一個意圖，若喚醒狀態客戶端發送PINGREQ消息之后，直接收到PINGRESP消息，表示網關當前暫時沒有為其緩存的消息可供發送。

很簡單，兩個字節表示足矣。

DISCONNECT

• 客戶端->網關，客戶端主動關閉當前連接，網關響應確認消息。只有表示自己進入睡眠狀態的客戶端，才會在DISCONNECT消息中附加Duration持續字段。
• 網關->客戶端，網關由于異常主動通知客戶端關閉兩者之間連接，客戶端接收到DISCONNECT時需要發送CONNECT消息到網關，重試重新建立連接。沒有Duration字段填充。

網關接收到要進入休眠狀態的客戶端發送的包含有Duration字段DISCONNECT消息時，可以直接返回2個字節的（不能包含有Duration字段）DISCONNECT消息以示確認。

WILLTOPICUPD

客戶端發送請求網關更新其遺囑主題。

標識位具體如下：

協議規定只有兩個字節空WILLTOPICUPD也是允許存在的，存在意義用于客戶端請求網關刪除已保存的遺囑主題和遺囑消息等。

WILLTOPICRESP

WILLTOPICRESP為網關收到WILLTOPICUPD后作出的應答消息。

WILLMSGUPD

客戶端->網關，確認更新的遺囑消息。

WILLMSGRESP

WILLMSGRESP為網關收到WILLMSGUPD后作出的應答消息。

轉發封裝

在MQTT-SN架構圖中，MQTT-SN Forwarder轉發器適用于客戶端無法直接訪問網關或當前傳感器網絡區域中不存在網關時，轉發器作用就體現出來了：

1. 接收MQTT-SN客戶端消息封裝后轉發給上游網關
2. 解封上游網關所發送消息，直接發送給對應客戶端

轉發器作用于消息的封裝轉發，解封發送，針對消息不做修改。

轉發器對MQTT-SN消息封裝格式：

無線節點Id（Wireless Node Id）：

• 轉發器->網關，無線節點Id為轉發器所在的無線節點Id，便于告知網關轉發器位置
• 網關->轉發器，無線節點Id為網關的無線節點Id

控制交換字段Ctrl，單個字節，位表示含義：

小結

MQTT-SN 1.2規范中所定義消息格式介紹完畢，下一篇將對MQTT-SN主要流程功、能進行闡述。