聂永的博客

记录工作/学习的点点滴滴。

MQTT协议笔记之发布流程

前言

这次要讲到客户端/服务器的发布消息行为,与PUBLISH相关的消息类型,会在这里看到。

PUBLISH

客户端发布消息经由服务器分发到所有对应的订阅者那里。一个订阅者可以订阅若干个主题(Topic name),但一个PUBLISH消息只能拥有一个主题。

消息架构一览:

 Description76543210
Fixed header/固定头部
byte 1   Message Type(3) DUP flag QoS level RETAIN
    0 0 1 1 0 0 1 0
byte 2 Remaining Length
Variable header/可变头部
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
Message Identifier
byte 6 Message ID MSB (0) 0 0 0 0 0 0 0 0
byte 7 Message ID LSB (10) 0 0 0 0 1 0 1 0
Playload/消息体
BLOB,二进制对象形式。二进制具体包含的内容和格式,可有应用程序自身定义。若消息体为空(0长度)也是可能的。

固定头部

DUP flag,设为0,表示当前为第一次发送。

RETAIN flag,只有在PUBLISH消息中才有效。

  • 1:表示发送的消息需要一直持久保存,不但要发送给当前的订阅者,并且以后新来的订阅了此Topic name的订阅者会马上得到推送。 备注:新来乍到的订阅者,只会取出最新的一个RETAIN flag = 1的消息推送,不是所有。
  • 0:仅仅为当前订阅者推送此消息。

可变头部

Topic name,UTF-8编码字符串形式,不支持通配符!

消息体

一般作为UTF-8编码写入接口,但不排除自定义的消息格式。

空的消息体(zero-length)的PUBLISH消息也可以是合法的。

当服务器接收到空消息体(zero-length payload)、retain = 1、具有topic name的一个PUBLISH特殊消息,表示同时满足retain = 1、相同topic name的这两个特征的被持久化PUBLISH消息,可被删除。

Response/响应

固定头部QoS level决定了消息中间件针对发布者具体需要响应的内容:

QoS Level Expected response
QoS 0 None
QoS 1 PUBACK
QoS 2 PUBREC

备注:仅仅针对发布PUBLISH消息的发布者。

Actions:

无论是订阅者还是服务器接收到PUBLISH消息之后,需要根据QoS level执行不同动作。

QoS Level Expected Action
QoS 0 发送到所有感兴趣者
QoS 1 持久化记录下来,发送到所有感兴趣的参与者,返回一个PUBACK消息给发送者
QoS 2 持久化记录下来,暂时不发送所有感兴趣的参与者,返回一个PUBREC消息给发送者

如果服务器收到PUBLISH消息,参与者指的是订阅者。如果订阅者收到PUBLISH消息,参与者就是服务器。 需要注意:

  1. 发布者发布的PUBLISH消息发送到服务器,在payload/消息体处可能夹带有私货,可能含有自定义的数据 格式
  2. 若兼容MQTT客户端,经由服务器分发到所有对应订阅者处只能是规规矩矩的PUBLISH消息,并且固定头部的RETAIN标志不能被设置成有效值1

授权

未经授权的发布者提交的PUBLISH消息,服务器会忽略掉,客户端不会被通知。

PUBACK

作为订阅者/服务器接收(QoS level = 1)PUBLISH消息之后对发送者的响应,整个消息不复杂。

 Description76543210
Fixed header/固定头部
byte 1   Message type (4) DUP flag QoS flags RETAIN
    0 1 0 0 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

虽没有消息体,但可变头部附加一个16位的无符号short类型。

PUBREC

字面意思为Assured publish received,作为订阅者/服务器对QoS level = 2的发布PUBLISH消息的发送方的响应,确认已经收到,为QoS level = 2消息流的第二个消息。 和PUBACK相比,除了消息类型不同外,其它都是一样。

 Description76543210
Fixed header/固定头部
byte 1   Message type (5) DUP flag QoS flags RETAIN
    0 1 0 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

无论是订阅者还是服务器,在消费PUBREC消息之后需要发送一个PUBREL消息给发送者(和PUBREC具有同样的消息ID),确认已收到。

PUBREL

Qos level = 2的协议流的第三个消息,有PUBLISH消息的发布者发送,参与方接收。完整示范如下:

 Description76543210
Fixed header/固定头部
byte 1   Message type (6) DUP flag QoS flags RETAIN
    0 1 1 0 0 0 1 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

QoS level 1,PUBREL消息要求如此。

DUP flag 为0,表示消息第一次被发送。

毫无疑问,剩余长度为2个byte长度。

可变头部中,消息ID和发布者接收到的PUBREC所包含的消息ID是一致的。

动作:

  1. 服务器接收到发布者(a)的PUBREL消息,此时服务器让发布者(a)刚才发布PUBLISH消息可用,发送此PUBLISH消息给所有订阅此主题的订阅者,然后发送PUBCOMP消息给发布者(a)
  2. 可变头部包含消息ID和服务器接收的PUBREL消息ID是一致的。 一个订阅者接收到PUBREL消息,订阅者使PUBLISH消息可用,然后反馈一个PUBCOMP消息给服务器

PUBCOMP

作为QoS level = 2消息流第四个,也是最后一个消息,由收到PUBREL的一方向另一方做出的响应消息。

完整的消息一览,和PUBREL一致,除了消息类型。

 Description76543210
Fixed header/固定头部
byte 1   Message type (7) DUP flag QoS flags RETAIN
    0 1 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

当客户端接收一个PUBCOMP消息时,客户端摒弃原来的消息,因为它已经成功发送消息到服务器。

小结

消息的发布和确认等一些流程,主要是跟消息发布者所设定的QoS level有关;稍加整理,绘制了下面一张图,理解起来可能会更清晰些:

Publish流程图

上图针对的是客户端发布消息到服务器端的方向。

为了确保消息已经成功传递过去,只有收到了确认,才会让人特别放心。

在QoS level = 2时,通信双方都需要知道各自的确认流程以及所处阶段等,交互很多,数据量大的情况下,可能会造成数据线路传递拥塞。服务器选择QoS = 0/1,大部分情况都是可以应对的。 比如重要消息,就要确保对方都要收到,然后彼此确认,OK,这个消息是真实、有效的。

无论Qos level为0、1,还是2,服务器(具备所有条件都满足之后)总要把收到的具体内容和topic组装成一个新的PUBLISH Message(也不一定要重新构造,但要求推送的PUBLISH消息,一定要具有明确的主题和内容,RETAIN标志不能设置为1)推送到所有感兴趣的订阅者。

嗯,消息的发布来源别忘记还有可能来自CONNECT消息中的Will Topic和Will Message,若是设置了Will flag标记的话。

posted on 2014-02-10 23:42 nieyong 阅读(17238) 评论(5)  编辑  收藏 所属分类: MQTT

评论

# re: MQTT协议笔记之发布流程 2014-02-11 08:14 鹏达锁业

期待博主更新文章。。。加油
  回复  更多评论   

# re: MQTT协议笔记之发布流程[未登录] 2015-10-26 16:56 123

请问,在服务器端,用代理转发的方式。是一个SUB订阅多个订阅号(多个设备的ID)->myaql 方式合理;还是实现多线程SUB,每一个线程的SUB订阅一个ID在同步到mysql的方式合理。  回复  更多评论   

# re: MQTT协议笔记之发布流程 2016-12-27 09:00 Haven

博主牛人呀,有一个QoS2的问题请教,为什么QoS2需要4次包,2次不就可以了吗?还望回复。  回复  更多评论   

# re: MQTT协议笔记之发布流程 2017-01-05 15:20 nieyong

@Haven

兄弟,针对QoS2,为了便于说明,我们先假设一个方向,Server -> Client:

----PUBLISH--->
<----PUBREC----
----PUBREL---->
<----PUBCOMP---

1. Server发送PUBLISH消息到Client,Client接收之后需要确认收到嘛,就返回PUBREC吧;但此时Client仅仅是把数据发送出去了而已,至于Server端收不收到那就不得而知
2. Server接收ClientPUBREC消息之后,需要回一个PUBREL消息告诉Client自己收到啦,同样道理也仅仅只是发送出去,Client是不是能收到的这个响应,心里面也没谱呀
3. Client收到来自Server的PUBREL之后,就非常明白自己针对PUBLISH消息做出的PUBREC响应消息在Server端是已经收到啦,但是需要告诉Server,自己收到它的再三确认啦
4. Server端此时等待Client上报PUBCOMP消息,一旦接收到之后,表示针对某个消息双方都再三确认了,这事就没有问题啦

其核心所设定网络是不靠谱的,任何一次发送数据到对端,都有可能因收不到(比如发送之后,某一端断网啦,或中间路由设备因为容量满了抛弃啦)。

好比双发约定一件事:

Server - 我给你说说这件事....
Client - 我同意了你这样做。
Server - 你确定你同意了?
Client - 是的,我同意了。
Server - OK,那这事就这么定了,我知道该怎么做啦。  回复  更多评论   

# re: MQTT协议笔记之发布流程 2017-01-10 13:03 Haven

@nieyong
谢谢兄弟的回复,

其实我还是觉得两次就可以搞定了。同样以Server -> Client为例

1. Server发送PUBLISH消息到Client,Client接收之后需要确认收到嘛,就返回PUBREC吧;但此时Client仅仅是把数据发送出去了而已,至于Server端收不收到那就不得而知.
2. Server可能收到了PUBREC,也可能没有收到
a. Server收到了PUBREC, 这时候就表示Client收到消息了,表示成功递送消息了。
b. Server没有收到PUBREC,等待一定时间后,重发PUBLISH即可。

在1中,Client收到PUBLISH后就把数据保存在数据库中,如果收到重复PUBLISH重数据库就可以知道是重复数据。
在2中,超时就重传PUBLISH即可。
感觉这样两步完全满足QoS2了呀!!


其实我在设计一套私有IM协议,用于自己的App中,希望能加你QQ探讨一下MQTT的QoS2问题。
我的QQ:357545146  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

所有文章皆为原创,若转载请标明出处,谢谢~

新浪微博,欢迎关注:

导航

<2014年2月>
2627282930311
2345678
9101112131415
16171819202122
2324252627281
2345678

统计

常用链接

留言簿(58)

随笔分类(130)

随笔档案(151)

个人收藏

最新随笔

搜索

最新评论

阅读排行榜

评论排行榜