欢迎光临seo外链资源网站,我们为你英文友情链接的信息及服务

seo外链资源

一个资源好的推广优化外链发布网站,为你解决外链获客难题

MQTT协议之消息发布

作者:jcmp      发布时间:2021-04-16      浏览量:0
这次要讲到客户端/服务器的发布消息行为,

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

PUBLISH

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

固定头部

DUP flag: 设为0,表示当前为第一次发送。 RETAIN flag: 只有在PUBLISH消息中才有效。 1: 表示发送的消息需要一直持久保存,不但要发送给当前的订阅者,并且以后新来的订阅了此Topic name的订阅者会马上得到推送。

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。

Actions:

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

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

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

授权

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

PUBACK

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

PUBREC

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

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

PUBREL

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

动作:

PUBCOMP

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

小结

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

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

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

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

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

主题和内容

,RETAIN标志不能设置为1)推送到所有感兴趣的订阅者。