MQTT协议会话中消息重发的思路实现(个人理解)

MQTT协议会话中消息重发的思路实现(个人理解)

最近用netty写了一个mqtt服务器,基础功能基本实现。记录重发逻辑的理解

qos0消息发布流程图

MQTT协议会话中消息重发的思路实现(个人理解)_第1张图片

qos1消息发布流程图

MQTT协议会话中消息重发的思路实现(个人理解)_第2张图片

qos2消息发布流程图

MQTT协议会话中消息重发的思路实现(个人理解)_第3张图片

MQTT协议会话中消息重发的思路实现(个人理解)

publish和pubrel的消息重发是针对订阅者而言的,重发是谁是发布者,才会担起这个责任,订阅者只是被动响应PUBACK、PUBREC或者PUBCOM

实现思路:

连接已连接状态:

​ 需要开启线程重发以下情况的消息:

1、没有收到puback、pubrec之前,要重发publish数据

​ 实现方案:出站write时就要开启周期性(假设设定每30s)重发任务,
​ 30s内收到puback、pubrec时(入站read),取消messageId对应的publish任务;

2、qos1的消息,第一种重发情况就已经解决;qos2收到pubrec时,发送pubrel。没有收到pubcom之前需要重发pubrel消息。

​ 实现方案:30s内收到pubrec时(入站read),取消对应的messageId的publish任务,
​ 要回复一个pubrel(出站write),同时开启周期性任务重发pubrel任务(假设设定每30s)
​ 30s内收到pubcom时(入站read),取消messageId对应的pubrel任务。
​ ps:所以收到pubrec后续只会重发pubrel消息,也就是说是不是收到pubrec之后就可以删除原来的publish本体消息了?或者保留下来没收到pubcom之前用作其他的用途。比如,需要msgId用完需要可重用,用作判断依据,所以我选择不删除。但收到pubcom消息时必须保证删除。

连接已断开状态(下次连接):

​ clearSession=1,清除对应客户端所有的会话历史消息
​ clearSession=0,下一次重连,publish、pubrel消息直接发送,重走注册周期性任务流程;

你可能感兴趣的:(物联网,java,网络协议,iot)