MQTT 3.1.1代理QOS=1（“至少一次”）消息重新传递

Question

null

为了更具体地说明我试图实现的目标:
推迟发送puback，直到成功持久化接收到的消息--有效地扩大QoS级别，直到我的订阅应用程序保证消息得到处理--这是一个好的/有效的想法吗？
以及对于例如持久化错误（数据库超时），是否会发送puback，这将自动导致重新传递此类消息。

最诚挚的问候

Answer 1

MQTT代理是否从订户重新传递未确认的“QoS 1”消息？

从[规格]:

当客户机将CleanSession设置为0时重新连接，客户机和服务器都必须使用它们的原始数据包标识符[MQTT-4.4.0-1]重新发送任何未确认的发布数据包（其中QoS>0)和PUBREL数据包。这是唯一需要客户端或服务器重新传递消息的情况。

根据上述规定，自动重试不是规范所要求的。一些经纪人可能会在一段时间后重新传输。emqx支持这一点；mosquitto过去有一个选项，但在1.5版本中删除了这个选项，更改日志解释说：。

QoS>1的传出消息在超时后不再重试。当客户端重新连接时，将重试消息。可以通过考虑超时可能发生的时间来证明这种行为的改变是合理的。

• 如果连接不可靠并已断开，但一端没有注意到，则在重新连接时将重试消息。发送附加的PUBLISH或PUBREL不会更改任何内容。
• 如果客户端过载/无法响应/连接缓慢，则发送额外的PUBLISH或PUBREL将无助于客户端赶上。一旦待办事项清理完毕，客户机就会响应。如果无法赶上，则发送额外的副本也无济于事

推迟发送PUBACK直到成功持久化接收到的消息是一个好的/有效的主意吗

几个月前，paho-dev集团对此进行了讨论。Go v5客户机正在考虑这个问题（目前该客户机自动确认消息）。

需要注意的一点是，MQTT规范确实有关于发送订单确认的要求。许多客户机忽略了这一要求（只在处理程序返回时发送确认），但有些客户机（例如HiveMQ Java客户机）将ACKs排队，以便能够以正确的顺序发送它们。