MQTT協議筆記之訂閱

2021-10-01 14:35:34 字數 4600 閱讀 8780

記憶不太好的時候,只能翻看以前的文章/筆記重新溫習一遍,但找不到mqtt協議有關訂閱部分的描述,好不容易從evernote中找到貼出來,這樣整個mqtt協議筆記,就比較齊全了。

一般來講,客戶端在成功建立tcp連線之後,傳送connect訊息,在得到伺服器端授權允許建立彼此連線的connack訊息之後,客戶端會傳送subscribe訊息,訂閱感興趣的topic主題列表(至少乙個主題),乙個完整示範如下:

description76

5432

10fixed header/固定頭部

byte 1

message type(8)

dup flag

qos level

retain10

0000

1xbyte 2

remaining length

variable header/可變頭部

message identifier

byte 1

message id msb (0)00

0000

00byte 2

message id lsb (10)00

0010

10playload/訊息體

topic name

byte 1

length msb (0)00

0000

00byte 2

length lsb (3)00

0000

11byte 3

'a' (0x61)01

1000

01byte 4

'/' (0x2f)00

1011

11byte 5

'b' (0x62)01

1000

10requested qos

byte 6

requested qos (1)xx

***x

01topic name

byte 7

length msb (0)00

0000

00byte 8

length lsb (3)00

0000

11byte 9

'c' (0x63)01

1000

11byte 10

'/' (0x2f)00

1011

11byte 11

'd' (0x64)01

1001

00requested qos

byte 12

requested qos (2)xx

***x

10固定頭部

qos level,可根據實際情況進行調整為0/1/2等。一般設為0表示最多一次。客戶端可設定oos level值。 dup flag,值為0表示第一次傳送。

可變頭部

因為上面示範qos level值為1,因此需要客戶端傳遞訊息id,16位,無符號的short型別。

訊息體訂閱的主題名稱採用修改版utf-8編碼,然後緊跟著對應的qos值。下面的次序,可能更為形象:

topic name

"a/b"

requested qos

1topic name

"c/d"

requested qos

2訂閱者的topic name支援萬用字元#和+ :

#支援乙個主題內任意級別話題

+只匹配乙個主題級別的萬用字元

eg:

finance/stock/#

finance/sotkc/ibm/+

都是有效,更具體規則,請參閱協議附加部分。

在伺服器接收處理時,按照順序讀取即可:

string topicname = readutf();

int qosval = read();

伺服器可以傳送qos不大於客戶端設定oos的訊息,尤其是伺服器不提供良好的持久化機制的時候。

伺服器會對發出subscribe的訊息返回乙個確認訊息。

description76

5432

10fixed header/固定頭部

byte 1

message type (9)

dup flag

qos flags

retain10

01xx

xxbyte 2

remaining length

variable header/可變頭部

message identifier

byte 1

message id msb (0)00

0000

00byte 2

message id lsb (10)00

0010

10playload/訊息體

byte 1

granted qos (0)xx

***x

00byte 1

granted qos (2)xx

***x

10可變頭部

message identifier,伺服器需要附加,客戶端需要處理。

訊息體qos,為伺服器根據實際情況授予的qos級別列表,和客戶端傳送的subscribe的訂閱topic name順序完全一致。

客戶端訂閱幾個topic,伺服器端一一給出各個topic的qos具體值。

伺服器需要支援客戶端取消訂閱功能,unsubscribe訊息格式和subscribe訊息格式差不多,除了訊息型別不同,訊息體中沒有了qos位元組,其它沒有區別。

description76

5432

10fixed header/固定頭部

byte 1

message type(10)

dup flag

qos level

retain10

1000

1xbyte 2

remaining length

variable header/可變頭部

message identifier

byte 1

message id msb (0)00

0000

00byte 2

message id lsb (10)00

0010

10playload/訊息體

topic name

byte 1

length msb (0)00

0000

00byte 2

length lsb (3)00

0000

11byte 3

'a' (0x61)01

1000

01byte 4

'/' (0x2f)00

1011

11byte 5

'b' (0x62)01

1000

10topic name

byte 6

length msb (0)00

0000

00byte 7

length lsb (3)00

0000

11byte 8

'c' (0x63)01

1000

11byte 9

'/' (0x2f)00

1011

11byte 10

'd' (0x64)01

1001

00可變頭部的訊息id的出現還是由固定頭部的qos level(1)決定是否存在。

一般來講,客戶端發布退訂,伺服器端需要返回退訂確認。

mqtt沒講是否允許客戶端退訂所有topic。

伺服器返回的unsubscribe訊息unsuback相應很簡單,沒有訊息體。

description76

5432

10fixed header/固定頭部

byte 1

message type (9)

dup flag

qos flags

retain10

11xx

xxbyte 2

remaining length (2)00

0000

10variable header/可變頭部

message identifier

byte 1

message id msb (0)00

0000

00byte 2

message id lsb (10)00

0010

10訂閱部分,共有四個訊息,分別一一對應。

命令響應

備註建議

subscribe

suback

協議沒有涉及最多執行訂閱topic數目,隱藏的隱患

建議至多10個

unsubscribe

unsuback

是否可以退訂所有訂閱,不詳

建議保留至少乙個topic

MQTT協議筆記之訂閱

記憶不太好的時候,只能翻看以前的文章 筆記重新溫習一遍,但找不到mqtt協議有關訂閱部分的描述,好不容易從evernote中找到貼出來,這樣整個mqtt協議筆記,就比較齊全了。一般來講,客戶端在成功建立tcp連線之後,傳送connect訊息,在得到伺服器端授權允許建立彼此連線的connack訊息之後...

MQTT協議筆記之訂閱

記憶不太好的時候,只能翻看以前的文章 筆記重新溫習一遍,但找不到mqtt協議有關訂閱部分的描述,好不容易從evernote中找到貼出來,這樣整個mqtt協議筆記,就比較齊全了。一般來講,客戶端在成功建立tcp連線之後,傳送connect訊息,在得到伺服器端授權允許建立彼此連線的connack訊息之後...

MQTT協議學習筆記

1 前沿 萬物聯網的時代即將到來,物聯網也由當初的概念開始進一步落實。隨著無線網路技術飛速發展,各種裝置都可以連線網路,實現遠端控制。例如智慧型家居最近非常火爆,智慧型插座 智慧型led燈 智慧型攝像頭等。在網際網路時代,http協議負責建立網路連線,而到了物聯網時代,由於智慧型硬體的差異,相比網際...