solaris中的TCP套接字recv在正确运行几天后超时[8-15天]为什么？

我们已经在Solaris平台C中实现了一个SFTP客户端应用程序。 应用程序可以正常工作几天，然后套接字操作[recv]失败 使用timeout，我们将timeout设置为120秒[2分钟]

重新启动流程后，一切正常

我想知道的是：

如何检查TCP错误的根本原因是什么<代码>错误号为150/某个时间超时错误

从哪里可以从系统日志文件中获取TCP错误的原因？在Solaris机器中

请提供一些建议，以便我能找到这个问题的根本原因

---

你也控制服务器端吗？服务器一直在运行吗？您是否可能与2台或更多服务器交互？如果最后是“是”，则您的ARP缓存可能已注明日期，不再与工作服务器对应。如果你控制服务器，让他们在引导时发送免费的ARP请求。我不知道solaris是如何做到这一点的，但这听起来像是一个ARP问题，你可以用tcpdump来监控。

据我在solaris上看到的，errno 150引用了

EINPROGRESS

，这可能是由

connect（）

调用设置的

我不确定

recv（）

是否会将errno设置为

EINPROGRESS

，至少在Linux上不会。因此，在查看

recv（）

时，您可能走错了方向

无论如何，通过

connect（）

将errno设置为

EINPROGRESS

并不一定表示错误，而是连接过程的异常行为，如预期的那样变慢

有关如何处理此类情况的详细信息，请参阅

connect（）

手册页

正如connect（）的Linux手册页所告诉我们的远不止Solaris手册页，我在此引用第一个：

EINPROGRESS插座未阻塞，无法立即完成连接。通过选择用于写入的套接字，可以选择（2）或轮询（2）以完成。在select（2）指示可写性后，使用getsockopt（2）读取SOL_SOCKET级别的SO_错误选项，以确定connect（）是成功完成（SO_错误为零）还是失败（SO_错误是此处列出的常见错误代码之一，解释了失败的原因）

---

这是不是只发生过一次？通常，可能会出现导致您使用连接性的小故障。如果检测到应用程序中的连接丢失并尝试重新建立连接，则可以避免重新启动该过程。您可能需要多次尝试，直到操作系统再次释放端口。当我们尝试重新建立连接时，与该服务器的所有连接都会失败，如果我们再次尝试重新启动该进程，请开始正常工作。服务器端的netstat（1）是您的朋友。可能是服务器的文件描述符不足。感谢您的回复，是的，客户端连接到多个serevr。如何在solaris中获取tcpdump？现在这个问题已经发生了，我们还要等几天再发生这个问题？我们现在可以获得旧的tcpdump了吗？如果是，如何获得？默认情况下，Solaris使用的是

snoop（1）

而不是

tcpdump

，请参见“是”-U r right，我在连接其他服务器时收到了错误号150。如果另一台服务器发生recv超时，这是否意味着网络有任何问题？当recv超时时，我将尝试再次连接到同一台服务器，但连接失败。[这里我没有错误号]