tcp - 在通过套接字发送消息之前延迟 - 这有什么帮助？

Question

我有一个第三方软件应用程序的 tcpip 套接字接口(interface)。我已经为几个客户站点实现了这个接口(interface)，没有任何问题。最新的客户，虽然......问题。我们已经打开了两端应用程序的登录功能，还在 PC 上安装了 Wireshark 以记录原始 tcpip 流量。这样，我们已经证明我的服务器应用程序成功发送了消息，PC 收到了消息，但客户端应用程序没有看到它。 (这是一个完全间歇性的问题，这就是为什么很难解决问题。)

套接字的细节很简单:一个套接字处理服务器和 pc 之间的双向通信。消息是纯 ASCII 文本并且相当短(不是 XML)。服务器通过发送第一条消息来启动通信，然后客户端用多条消息进行响应。在应用程序运行时，套接字始终保持打开状态。客户端应用程序的设计使最终用户一次只能处理一个案例，从而防止发生消息冲突。他们设置了某种轮询，他们的应用程序会“休眠”，直到它看到来自服务器的启动消息。

第三方供应商建议我在向他们发送启动消息之前增加几秒钟的延迟。我看不出这有什么帮助。如果客户端正在“休眠”，只是轮询等待消息的套接字，那么在第一条消息之前添加延迟有何帮助？这不像我们发送了两条消息而第二条消息丢失了。它正在丢失第一条消息。所以我不明白我们是现在还是两秒后发送这条消息有什么关系。

我问过他们，他们没有给我详细信息。他们可能不想向我透露他们编码中的一些专有细节，这很公平。所以我在这里问是因为我一直在学习有关套接字编程的新知识。也许你们可以阐明轮询 tcpip 套接字如何受消息计时的影响？

Answer 1

因为它是其他人的客户，他们不会告诉你它在做什么(除了说“插入延迟”)，答案可能是他们的客户正在阅读并丢弃消息，因为它还没有处于处理它。延迟将使客户端有时间进入可以正确响应消息的状态。

换句话说，客户端存在竞争条件。发生这种情况的一种简单方法是，如果他们有一个线程用于读取消息而另一个线程用于处理消息。

如果没有在客户端上运行 strace(1) 来查看它正在调用什么系统，则很难判断客户端实际在做什么。