EMQ 学习---MQTT消息QoS

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来保证消息不会重复接收和发送!

posted on 2018-10-13 12:04  清明-心若淡定  阅读(6383)  评论(0编辑  收藏  举报