来自发布的MQTT recv和MQTT ping C

我遇到了这个问题，在一个测试程序中，我正在为MQTT开发一个客户机，我订阅了一个主题，然后，我等待从服务器到我的客户机的“发布”消息

在一个好的recv（发布消息）或recv超时之后，我向服务器发送一个mqtt-PINGREQ

在PINGREQ之后，我将等待PINGRESP，然后调用recv，就像我在等待发布消息一样

如果流程是这样的：

Client -> PINGREQ
Server -> PUBLISH
Server -> PINGRESP

---

服务器发布消息丢失。如何解决这个问题？我在QOS 0上使用MQTT，在这个QOS级别上解决这个问题是有意义的，或者在QOS1上检查这个案例是明智的？

我认为您有点困惑。当客户端和服务器之间没有任何其他网络流量通过时，使用PINGREQ/PINGRESP，以便让客户端和服务器都知道连接是否断开

您的客户机应该跟踪与服务器的最后一次传出或传入通信是在什么时候进行的，如果PINGREQ将超过其使用CONNECT命令设置的keepalive计时器，则应发送PINGREQ。如果没有收到任何通信，服务器将在1.5*keepalive断开客户端。如果在发送PINGREQ的保持期内没有收到响应其PINGREQ的PINGRESP，则客户端应假定服务器已断开连接

QoS级别没有那么重要，您必须确保保持keepalive超时

---

我还想到，这听起来像是在使用阻塞网络呼叫——如果可以的话，最好转到非阻塞，以获得更大的灵活性。

谢谢，我正在转到非阻塞呼叫。通过这种方式，我的客户机很可能正在接收PINGREQ，并且有一个发布传入，对吗？这就是好处？我现在正在测试在接收过程中不使用ping来发布更多数据，在所有数据到达之后，服务器似乎关闭了连接。从服务器发布到客户端时，计时器似乎没有重置。非阻塞调用的显著优点是，在调用recv（）后，您不必等到传入数据到达。服务器希望客户端的网络通信重置计时器，这是它知道客户是否在那里的方式。向客户端发送数据不会告诉它任何东西，除非有回复。不幸的是，如果您只从服务器接收数据，那么您确实需要每隔keepalive秒发送一次PINGREQ。另一个想法是，有什么原因不能使用现有的客户端库吗？