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

我正在尝试了解MQTT订户通过“至少一次”（QoS 1）配置接收的消息的MQTT 3.1.1消息重新传递的现实情况：

• MQTT代理是否从订阅者重新传递未确认的“QoS 1”消息
• MQTT代理重新交付之前必须经过多长时间
• MQTT代理是否无休止地尝试重新传递未确认的消息
• 是否有其他方式触发重新交付

假设MQTT订阅者没有对接收到的MQTT消息响应

PUBACK

消息，MQTT代理需要（至少据我所知）重新传递必须“至少一次”接收的消息，直到订阅者为该消息发送

PUBACK

要更具体地了解我正在努力实现的目标：
推迟发送

PUBACK

直到成功保存接收到的消息，这是否是一个好的/有效的主意-有效地提高QoS水平，直到我的订阅应用程序保证消息得到处理。
例如，对于持久性错误（数据库超时），是否不会发送

PUBACK

，这将自动导致此类消息的重新传递

Thx&best ADVICES

MQTT代理是否从订阅者处重新发送未确认的“QoS 1”消息

根据[规范]：

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

因此，是的，未确认的QOS1消息将被重新传递，但规范要求这种情况发生的唯一时间是当客户端重新连接时

当您声明正在使用MQTT v3.1.1时，我认为值得注意的是，除了重新连接之外，明确禁止重新交付：

当客户机重新连接且Clean Start设置为0且存在会话时，客户机和服务器都必须使用原始数据包标识符重新发送任何未确认的发布数据包（其中QoS>0）和PUBREL数据包。这是唯一需要客户端或服务器重新发送消息的情况。客户端和服务器不得在任何其他时间重新发送消息

MQTT代理重新交付之前必须经过多长时间

如上所述，规范不要求自动重试。一些代理可能会在一段时间后重新传输。支持这一点；mosquitto以前有一个选项，但在版本1.5中删除了该选项，解释如下：

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

• 如果连接不可靠且已断开，但没有一端 请注意，消息将在重新连接时重试。发送 额外的发布或发布不会改变任何事情
• 如果客户端过载/无法响应/连接速度慢，则 发送额外的PUBLISH或PUBREL不会帮助客户端捕获 向上的一旦积压工作清理完毕，客户将作出响应。如果不是 如果能够赶上，发送额外的副本也不会有帮助

MQTT代理是否无休止地尝试重新传递未确认的消息

3.11规范没有提供任何指导（因此，理论上是的），但许多代理对此提供了一些控制（排队的消息的最大数量、队列的最大大小等）

是否有其他方式触发重新交付

是-断开并重新连接

推迟发送PUBACK，直到成功保存收到的消息，这是一个好的/有效的主意吗

关于这一点，在会议上进行了讨论。这是在中考虑的内容（当前客户端自动确认消息）

需要注意的一件事是，MQTT规范确实对。许多客户端忽略了这一要求（并且在处理程序返回时只发送确认），但一些（例如）客户端将确认排队，以便能够以正确的顺序发送。

MQTT代理是否从订阅者重新发送未确认的“QoS 1”消息

根据[规范]：

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

因此，是的，未确认的QOS1消息将被重新传递，但规范要求这种情况发生的唯一时间是当客户端重新连接时

当您声明正在使用MQTT v3.1.1时，我认为值得注意的是，除了重新连接之外，明确禁止重新交付：

当客户机重新连接且Clean Start设置为0且存在会话时，客户机和服务器都必须使用原始数据包标识符重新发送任何未确认的发布数据包（其中QoS>0）和PUBREL数据包。这是唯一需要客户端或服务器重新发送消息的情况。客户端和服务器不得在任何其他时间重新发送消息

MQTT代理重新交付之前必须经过多长时间

如上所述，规范不要求自动重试。一些代理可能会在一段时间后重新传输。支持这一点；mosquitto以前有一个选项，但在版本1.5中删除了该选项，解释如下：

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