五.MQTT协议笔记之订阅

前言

记忆不太好的时候,只能翻看以前的文章/笔记重新温习一遍,但找不到MQTT协议有关订阅部分的描述,好不容易从Evernote中找到贴出来,这样整个MQTT协议笔记,就比较齐全了。

SUBSCRIBE

一般来讲,客户端在成功建立TCP连接之后,发送CONNECT消息,在得到服务器端授权允许建立彼此连接的CONNACK消息之后,客户端会发送SUBSCRIBE消息,订阅感兴趣的Topic主题列表(至少一个主题),一个完整示范如下:


Description 7 6 5 4 3 2 1 0
Fixed header/固定头部
byte 1   Message Type(8) DUP flag QoS level RETAIN
    1 0 0 0 0 0 1 x
byte 2 Remaining Length
Variable header/可变头部
Message Identifier
byte 1 Message ID MSB (0) 0 0 0 0 0 0 0 0
byte 2 Message ID LSB (10) 0 0 0 0 1 0 1 0
Playload/消息体
Topic name
byte 1 Length MSB (0) 0 0 0 0 0 0 0 0
byte 2 Length LSB (3) 0 0 0 0 0 0 1 1
byte 3 'a' (0x61) 0 1 1 0 0 0 0 1
byte 4 '/' (0x2F) 0 0 1 0 1 1 1 1
byte 5 'b' (0x62) 0 1 1 0 0 0 1 0
Requested QoS
byte 6 Requested QoS (1) x x x x x x 0 1
Topic Name
byte 7 Length MSB (0) 0 0 0 0 0 0 0 0
byte 8 Length LSB (3) 0 0 0 0 0 0 1 1
byte 9 'c' (0x63) 0 1 1 0 0 0 1 1
byte 10 '/' (0x2F) 0 0 1 0 1 1 1 1
byte 11 'd' (0x64) 0 1 1 0 0 1 0 0
Requested QoS
byte 12 Requested QoS (2) x x x x x x 1 0

固定头部

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 1
Topic name "c/d"
Requested QoS 2

订阅者的Topic name支持通配符#和+ :

  1. #支持一个主题内任意级别话题
  2. +只匹配一个主题级别的通配符

eg:

finance/stock/#
finance/sotkc/ibm/+

都是有效,更具体规则,请参阅协议附加部分。

在服务器接收处理时,按照顺序读取即可:

String topicName = readUTF();
int qosVal = read();

服务器可以发送QoS不大于客户端设置OoS的消息,尤其是服务器不提供良好的持久化机制的时候。

SUBACK

服务器会对发出SUBSCRIBE的消息返回一个确认消息。


Description 7 6 5 4 3 2 1 0
Fixed header/固定头部
byte 1   Message type (9) DUP flag QoS flags RETAIN
    1 0 0 1 x x x x
byte 2   Remaining Length
Variable header/可变头部
Message Identifier
byte 1 Message ID MSB (0) 0 0 0 0 0 0 0 0
byte 2 Message ID LSB (10) 0 0 0 0 1 0 1 0
Playload/消息体
byte 1 Granted QoS (0) x x x x x x 0 0
byte 1 Granted QoS (2) x x x x x x 1 0

可变头部

Message Identifier,服务器需要附加,客户端需要处理。

消息体

QoS,为服务器根据实际情况授予的QoS级别列表,和客户端发送的SUBSCRIBE的订阅Topic Name顺序完全一致。

客户端订阅几个TOPIC,服务器端一一给出各个TOPIC的QoS具体值。

UNSUBSCRIBE

服务器需要支持客户端取消订阅功能,UNSUBSCRIBE消息格式和SUBSCRIBE消息格式差不多,除了消息类型不同,消息体中没有了QoS字节,其它没有区别。


Description 7 6 5 4 3 2 1 0
Fixed header/固定头部
byte 1   Message Type(10) DUP flag QoS level RETAIN
    1 0 1 0 0 0 1 x
byte 2 Remaining Length
Variable header/可变头部
Message Identifier
byte 1 Message ID MSB (0) 0 0 0 0 0 0 0 0
byte 2 Message ID LSB (10) 0 0 0 0 1 0 1 0
Playload/消息体
Topic name
byte 1 Length MSB (0) 0 0 0 0 0 0 0 0
byte 2 Length LSB (3) 0 0 0 0 0 0 1 1
byte 3 'a' (0x61) 0 1 1 0 0 0 0 1
byte 4 '/' (0x2F) 0 0 1 0 1 1 1 1
byte 5 'b' (0x62) 0 1 1 0 0 0 1 0
Topic Name
byte 6 Length MSB (0) 0 0 0 0 0 0 0 0
byte 7 Length LSB (3) 0 0 0 0 0 0 1 1
byte 8 'c' (0x63) 0 1 1 0 0 0 1 1
byte 9 '/' (0x2F) 0 0 1 0 1 1 1 1
byte 10 'd' (0x64) 0 1 1 0 0 1 0 0

可变头部的消息ID的出现还是由固定头部的QoS Level(1)决定是否存在。

一般来讲,客户端发布退订,服务器端需要返回退订确认。

MQTT没讲是否允许客户端退订所有TOPIC。

UNSUBACK

服务器返回的UNSUBSCRIBE消息UNSUBACK相应很简单,没有消息体。


Description 7 6 5 4 3 2 1 0
Fixed header/固定头部
byte 1   Message type (9) DUP flag QoS flags RETAIN
    1 0 1 1 x x x x
byte 2   Remaining length (2)
    0 0 0 0 0 0 1 0
Variable header/可变头部
Message Identifier
byte 1 Message ID MSB (0) 0 0 0 0 0 0 0 0
byte 2 Message ID LSB (10) 0 0 0 0 1 0 1 0

小结

订阅部分,共有四个消息,分别一一对应。

命令 响应 备注 建议
SUBSCRIBE SUBACK 协议没有涉及最多运行订阅TOPIC数目,隐藏的隐患 建议至多10个
UNSUBSCRIBE UNSUBACK 是否可以退订所有订阅,不详 建议保留至少一个Topic

 

转自:http://www.blogjava.net/yongboy/archive/2014/04/12/412351.html

此条目发表在message分类目录,贴了标签。将固定链接加入收藏夹。