MQTT协议(三) PUBLISH

一、服务器<----->PUBLISH<------>客户端

可以发布消息从publisher发送到服务器,或从服务器到subscriber。一个订阅者可以订阅若干个主题(Topic name),但一个PUBLISH消息只能拥有一个主题。

例如下面是一个PUBLISH消息:

MQTT协议(三) PUBLISH_第1张图片


1、固定头部

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

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

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

        为0:仅仅为当前订阅者推送此消息,这意味不保留。


2、可变头部

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

    Message ID,代表QoS level 1QoS level 2消息。


3、消息体

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

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

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


二、Response :即服务器PUBLISH到客户端后,客户端的响应(反过来也是)

    由PUBLISH消息中定义的QoS Level值来决定客户端该如何响应服务器,规则如下:

MQTT协议(三) PUBLISH_第2张图片

    注意:这个规则仅仅用在仅仅针对发布PUBLISH消息的发布者。


三、Action

    可以发布消息从publisher发送到服务器,或从服务器到subscriber。当它接收到一条消息时接收者的行动取决于消息的QoS level

MQTT协议(三) PUBLISH_第3张图片

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

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

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


五、PUBACK(仅一次回应)

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

MQTT协议(三) PUBLISH_第4张图片

    虽没有消息体,但可变头部附加一个16位的无符号short类型,表明一个被确认的PUBLISH消息的消息标识符(Message ID 。


六、PUBREC(第一次回应)

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

MQTT协议(三) PUBLISH_第5张图片

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


七、PUBREL(第二次回应)

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

MQTT协议(三) PUBLISH_第6张图片

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

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

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

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

八、PUBCOMP(第三次回应)

    作为QoS level = 2消息流第四个(第三个回应),也是最后一个消息,由收到PUBREL的一方向另一方做出的响应消息。完整的消息一览,和PUBREL一致,除了消息类型。

MQTT协议(三) PUBLISH_第7张图片

   能跑得到这里,表明发送成功了!!!!当客户端接收一个PUBCOMP消息时,客户端摒弃原来的消息,因为此时它已经成功发送消息到服务器。


总结:

    下面是一张流程图,针对的是客户端发布消息到服务器端的方向:

MQTT协议(三) PUBLISH_第8张图片



    说明一下:

        QoS level = 2时,通信双方都需要知道各自的确认流程以及所处阶段等,交互很多,数据量大的情况下,可能会造成数据线路传递拥塞。

       QoS = 0/1,大部分情况都是可以应对的。

       除非是重要消息,就要确保对方都要收到,然后彼此确认,OK,这个消息是真实、有效的。


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


参考自:MQTT 3.1 官方文档


你可能感兴趣的:(mosquitto)