緊接着上篇初步介紹,本文爲第二篇,主要梳理MQTT-SN 1.2協議中定義的消息格式。html
消息頭 | 其它可變部分 |
---|---|
2/4字節表示 | N字節組成 |
長度 | 消息類型 |
---|---|
1或3個字節 | 1個字節 |
備註:java
MQTT-SN不支持消息的分片和重組。底層網絡所定義數據包長度若小於MQTT-SN消息的最大長度,自身進行的分片和重組,對MQTT-SN協議自己不受影響。
MQTT-SN定義的消息類型數量衆多,超過25個,感受有些頭大。緩存
消息類型值 | 消息類型名稱 | 說明 |
---|---|---|
0x00 | ADVERTISE | 廣播消息 |
0x01 | SEARCHGW | 尋找網關 |
0x02 | GWINFO | 網關信息 |
0x03 | reserved | 沒有使用到 |
0x04 | CONNECT | 發起鏈接 |
0x05 | CONNACK | 鏈接確認 |
0x06 | WILLTOPICREQ | 遺囑主題請求 |
0x07 | WILLTOPIC | 遺囑主題確認 |
0x08 | WILLMSGREQ | 遺囑消息請求 |
0x09 | WILLMSG | 遺囑消息確認 |
0x0A | REGISTER | 註冊主題 |
0x0B | REGACK | 註冊確認 |
0x0C | PUBLISH | 發佈消息 |
0x0D | PUBACK | 發佈確認 |
0x0E | PUBCOMP | 發佈環節消息 |
0x0F | PUBREC | 發佈環節消息 |
0x10 | PUBREL | 發佈環節消息 |
0x11 | reserved | 保留字段 |
0x12 | SUBSCRIBE | 訂閱主題 |
0x13 | SUBACK | 訂閱確認 |
0x14 | UNSUBSCRIBE | 退訂 |
0x15 | UNSUBACK | 退訂確認 |
0x16 | PINGREQ | Ping請求 |
0x17 | PINGRESP | Ping響應 |
0x18 | DISCONNECT | 斷開 |
0x19 | reserved | 保留字段 |
0x1A | WILLTOPICUPD | 遺囑主題更新 |
0x1B | WILLTOPICRESP | 遺囑主題更新確認 |
0x1C | WILLMSGUPD | 遺囑消息更新 |
0x1D | WILLMSGRESP | 遺囑消息更新確認 |
0x1E-0xFD | reserved | 保留字段 |
0xFE | 轉發封裝標誌 | 用於轉發 |
可變字段不少,與MQTT相比,多了:服務器
返回值 | 返回值含義 |
---|---|
0x00 | 接受請求(Accepted) |
0x01 | 因擁塞拒絕(Rejected: congestion),通常須要接收方等待T_WAIT時間長 |
0x02 | 因非法主題標識符拒絕(Rejected: invalid topic ID) |
0x03 | 因不支持拒絕(Rejected: not supported) |
0x04 - 0xFF | 保留,沒有使用到 |
網關週期性會對當前網絡下全部客戶端、節點進行廣播,用於客戶端發現可用網關。網絡
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x05 |
1 | MsgType | 0x00 |
2 | GwId | 網關須要吧自身標識符包含其中 |
3-4 | Duration | 網關的下次廣播間隔時長,單位秒 |
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x03 |
1 | MsgType | 0x01 |
2 | Radius | 廣播半徑深度,同時也是隻是給當前網絡傳輸層 |
客戶端主動尋找網關進行廣播的消息,廣播路徑範圍受限於當前網絡環境下的客戶端部署密度,好比只有1跳廣播在很是密集的網絡環境下客戶端均可以彼此互相訪問。架構
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態肯定 |
1 | MsgType | 0x02 |
2 | GwId | 網關Id |
3-n | GwAdd* | 一個網關地址,僅僅由客戶端發出消息時,此字段才存在 |
GWINFO做爲對SEARCHGW消息的響應:less
客戶端向網關發出創建鏈接的消息。.net
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x04 |
2 | Flags | 標誌位 |
3 | ProtocolId | 0x01,表示協議版本和協議名稱 |
4-5 | Duration | 存活持續時長 |
6-n | ClientId | 客戶端標識符,1-23個字節表示的字符串 |
在CONNECT消息標誌位具體表示以下:code
DUP | QoS | Retain | Will | CleanSession | TopicIdType |
---|---|---|---|---|---|
bit 7 | 6,5 | 4 | 3 | 2 | 1,0 |
X | X | X | 0/1 | 0/1 | X |
在Flags中使用到的標誌位:htm
網關對客戶端發出CONNECT消息的響應。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x03 |
1 | MsgType | 0x05 |
2 | ReturnCode | 接受值0x00,拒絕爲0x01-0x03,具體見上文RecodeCode定義 |
根據客戶端CONNECT標誌位中WILL字段爲true狀況下,網關向客戶端發出遺囑主題請求,格式以下:
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x02 |
1 | MsgType | 0x06 |
只有頭部部分,很簡單。
客戶端做爲網關WILLTOPICREQ請求響應消息。下面是一個正常版本的WILLTOPIC消息:
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x07 |
2 | Flags | 標誌位 |
3-n | WillTopic | 遺囑主題 |
此時的標誌位以下
DUP | QoS | Retain | Will | CleanSession | TopicIdType |
---|---|---|---|---|---|
bit 7 | 6,5 | 4 | 3 | 2 | 1,0 |
X | 0x00-0x02 | 0/1 | X | X | X |
而空的WILLTOPIC也是容許存在的,就兩個字節表示,用於客戶端請求刪除已存在於服務器端的對應遺囑主題和消息。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x02 |
1 | MsgType | 0x07 |
根據客戶端CONNECT標誌位中WILL字段爲真狀況下,網關向客戶端發出遺囑消息請求,格式以下:
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x02 |
1 | MsgType | 0x08 |
只有頭部部分,沒有別的。
客戶端對網關WILLMSGREQ請求的響應,從而把遺囑消息傳遞給網關進行保存。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x09 |
2-n | WillMsg | 客戶端遺囑 |
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x0A |
2-3 | TopicId | 客戶端發出,此值爲0x0000;服務器發出,須要包含對應於Topic Name的主題標識符 |
4-5 | MsgId | 天然數,用以標識對應的REGACK確認 |
6-n | TopicName | 主題名稱,不能太長,儘可能不要使用通配符 |
客戶端或網關針對REGISTER消息的響應。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x07 |
1 | MsgType | 0x0B |
2-3 | TopicId | 對應於Topic Name的主題標識符,被用於PUBLISH消息發佈 |
4-5 | MsgId | 天然數,用以標識對應的REGISTER消息 |
6 | ReturnCode | 0x00被接受,其它值被拒絕 |
PUBLISH消息用於客戶端或網關發佈消息用:
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x0C |
2 | Flags | 標誌位 |
3-4 | TopicId | 主題標識符 |
5-6 | MsgId | QoS 1-2時須要填充天然值;QoS 0時,值爲0x0000 |
7-n | Data | 用於發佈的具體消息內容 |
標識位具體以下:
DUP | QoS | Retain | Will | CleanSession | TopicIdType |
---|---|---|---|---|---|
bit 7 | 6,5 | 4 | 3 | 2 | 1,0 |
0/1 | 0x00-0x02 | 0/1 | X | X | 0b00/0b01/0b10 |
標識位裏面各個字段和MQTT協議一致,無須多解釋。
客戶端/網關僅僅對QoS 1/2的PUBLISH消息作出響應。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x07 |
1 | MsgType | 0x0D |
2-3 | TopicId | 對應PUBLISH消息中TopicId |
4-5 | MsgId | 天然數,用以標識對應的REGISTER消息 |
6 | ReturnCode | 0x00被接受,其它值被拒絕,不一樣值表示不一樣拒絕理由 |
處理PUBLISH消息異常?在PUBACK消息中的ReturnCode字段中以相應值體現出來,這就要求接收者處理拒絕理由。
只有在PUBLISH消息中QoS 2時,PUBREC, PUBREL, PUBCOMP纔會一塊兒登場,不然是沒有出場機會的。消息格式嘛,都很統一:
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x04 |
1 | MsgType | 0x0F/0x10/0x0E |
2-3 | MsgId | 對應PUBLISH消息中的MsgId |
SUBSCRIBE用於客戶端訂閱某個主題的消息。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x12 |
2 | Flags | 標誌位 |
3-4 | MsgId | 用於肯定對應的訂閱確認SUBACK消息 |
5-N | TopicId/TopicName | 具體須要根據Flags標誌位中TopicIdType進行填充 |
標識位具體以下:
DUP | QoS | Retain | Will | CleanSession | TopicIdType |
---|---|---|---|---|---|
bit 7 | 6,5 | 4 | 3 | 2 | 1,0 |
0/1 | 0x00-0x02 | X | X | X | 0b00/0b01/0b10 |
此處,標誌位中TopicIdType決定了SUBSCRIBE消息中TopicId/TopicName字段具體填充值:預約義topic id,或短小兩個字符表示主題(topic name),或直接填寫主題。
網關->客戶端,訂閱處理狀況的確認回執,接受訂閱或出於其它緣由拒絕之。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x08 |
1 | MsgType | 0x13 |
2 | Flags | 標誌位 |
3-4 | TopicId | 網關接受其註冊,此處對應具體指派的TopicId |
5-6 | MsgId | SUBSCRIBE消息中對應MsgId值 |
7 | ReturnCode | 0x00被接受,其它值被拒絕 |
標識位具體以下:
DUP | QoS | Retain | Will | CleanSession | TopicIdType |
---|---|---|---|---|---|
bit 7 | 6,5 | 4 | 3 | 2 | 1,0 |
X | 0x00-0x02 | X | X | X | X |
SUBACK消息標誌位中QoS爲網關根據實際狀況受權後的QoS具體值,這也應該是客戶端須要知道並處理的。
UNSUBSCRIBE用於客戶端取消訂閱某個主題的消息。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x14 |
2 | Flags | 標誌位 |
3-4 | MsgId | 用於肯定對應的退訂確認UNSUBACK消息 |
5-N | TopicId/TopicName | 具體須要根據Flags標誌位中TopicIdType進行填充 |
標識位具體以下:
DUP | QoS | Retain | Will | CleanSession | TopicIdType |
---|---|---|---|---|---|
bit 7 | 6,5 | 4 | 3 | 2 | 1,0 |
X | X | X | X | X | 0b00/0b01/0b10 |
UNSUBSCRIBE消息標誌位中惟一可用屬性TopicIdType決定了UNSUBSCRIBE消息中TopicId/TopicName字段具體填充值。
網關->客戶端,取消訂閱處理狀況的確認回執,很簡單,4個字節表示。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x04 |
1 | MsgType | 0x15 |
2-3 | MsgId | UNSUBSCRIBE消息中對應MsgId值 |
和MQTT協議中的PINGREQ一致,存活檢測。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x16 |
2-N | ClientId | 可選項,表示客戶端休眠狀態轉換爲喚醒狀態用於檢查網關是否爲其緩存消息 |
接受PINGREQ消息的一方,如網關響應PINGRESP消息表示本身如今運行OK。
另一個意圖,若喚醒狀態客戶端發送PINGREQ消息以後,直接收到PINGRESP消息,表示網關當前暫時沒有爲其緩存的消息可供發送。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x02 |
1 | MsgType | 0x17 |
很簡單,兩個字節表示足矣。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x18 |
2-3 | Duration | 可選項,表示客戶端即將進入睡眠狀態的持續時間值 |
網關接收到要進入休眠狀態的客戶端發送的包含有Duration字段DISCONNECT消息時,能夠直接返回2個字節的(不能包含有Duration字段)DISCONNECT消息以示確認。
客戶端發送請求網關更新其遺囑主題。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x1A |
2 | Flags | 標誌位 |
3-N | WillTopic | 用於更新的遺囑主題 |
標識位具體以下:
DUP | QoS | Retain | Will | CleanSession | TopicIdType |
---|---|---|---|---|---|
bit 7 | 6,5 | 4 | 3 | 2 | 1,0 |
X | 0x00-0x02 | 0/1 | X | X | X |
協議規定只有兩個字節空WILLTOPICUPD也是容許存在的,存在乎義用於客戶端請求網關刪除已保存的遺囑主題和遺囑消息等。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x02 |
1 | MsgType | 0x1A |
WILLTOPICRESP爲網關收到WILLTOPICUPD後做出的應答消息。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x03 |
1 | MsgType | 0x1B |
2 | ReturnCode | 0x00被接受,其它值被拒絕 |
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 動態計算 |
1 | MsgType | 0x1C |
2-N | WillMsg | 用於更新的遺囑消息 |
客戶端->網關,確認更新的遺囑消息。
WILLMSGRESP爲網關收到WILLMSGUPD後做出的應答消息。
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 0x03 |
1 | MsgType | 0x1D |
2 | ReturnCode | 0x00被接受,其它值被拒絕 |
在MQTT-SN架構圖中,MQTT-SN Forwarder轉發器適用於客戶端沒法直接訪問網關或當前傳感器網絡區域中不存在網關時,轉發器做用就體現出來了:
轉發器做用於消息的封裝轉發,解封發送,針對消息不作修改。
轉發器對MQTT-SN消息封裝格式:
字節索引 | 表示內容 | 說明 |
---|---|---|
0 | Length | 十進制表示長度就是N |
1 | MsgType | 0xFE |
2 | Ctrl | 包含網關和轉發器之間的控制交換信息,主要是前兩位包含了半徑範圍 |
3-N | Wireless Node Id | 標識所發目的或須要接收封裝消息的無線節點 |
N+1-M | MQTT-SN message | 一個MQTT-SN消息消息 |
無線節點Id(Wireless Node Id):
控制交換字段Ctrl,單個字節,位表示含義:
bit 7,2 | 1,0 |
---|---|
X | 0x00-0x03 |
MQTT-SN 1.2規範中所定義消息格式介紹完畢,下一篇將對MQTT-SN主要流程功、能進行闡述。
原文 http://www.blogjava.net/yongboy/archive/2015/01/08/422142.html