EMQ 学习---MQTT消息QoS

标签：没有   sub   conf   pytho   png   完成   相同   还需   cli   

MQTT发布消息QoS保证不是端到端的，是客户端与服务器之间的。订阅者收到MQTT消息的QoS级别，最终取决于发布消息的QoS和主题订阅的QoS。

客户端连接:

客户端完成TCP三次握手之后，还需要发起CONNECT命令

注意：如果客户端三次握手之后，不发起MQTT的CONNECT命令，30s之后会被服务器断掉。

emqttd.config文件有定义这个时间间隔：

 %% Client
        {client, [
            %% Socket is connected, but no ‘CONNECT‘ packet received
            {idle_timeout, 30} %% seconds
        ]},

只有QoS==1,2时候，才有Store(Msg)之说；QoS==0时没有。

我们以第一种action为例（注意这里第一种action存储的是message，第二种action存储的是message ID）：
1 若client没收到来自sever的pubcomp：那么client将重发pubrel，意思是sever将收到两次pubrel；但是sever并不会将消息发送两次，因为在第一次将消息发送给订阅者之后，server将删除这条消息的内容（delete message），而消息的内容是在publish中传输的，而不是在pubrel中传输的；
2 若client没收到来自server的pubrec，那么client将重发publish，意思是sever将收到两次publish，但是这里sever只是存储了信息，而且后面在pubrec中会有消息的ID，而client可以根据两次ID是否相同来判断server收到了几次同样的消息。
综上所述，这就保证了server不会将消息重发。

对于QoS2，增加了一个PUBREL及PUBCOM的过程，这样可以保证server端只publish一条message给他的subscriber。但是QoS1是只要sever接收到message就会publish给他的subscriber，网络不好的时候sender是会重复发送相同的message的，server也就会重复publish相同的message给他的。

QoS2的server端处理逻辑有点特别：

如果sender没收到server的PUBRECV， sender 是会重发，但是对于头上一条message，server有两种处理方式：1, message存在本地，先不publish给subscriber；2，存下message ID，把message publish 给他的subscriber。

对于第一种处理方式，如果sender继续重发，且被收到（ID相同），那在server端只算一条message，继续等sender发PUBREL，这样server就保证只publish了一条message，而不是多条。

对于第二种处理方式，如果sender继续重发，且被收到，sever会检查它的message ID，如果重发过来的message ID是之前存过的，server就不会publish给他的subscriber，因为之前已经publish了。直接删除。

总之，QoS==1,2时候，有Store(Msg)和唯一的MessageID来保证消息不会重复接收和发送！

EMQ 学习---MQTT消息QoS

标签：没有   sub   conf   pytho   png   完成   相同   还需   cli   

原文地址：https://www.cnblogs.com/saryli/p/9782421.html