Socket在应用程序崩溃后仍然侦听 [英] Socket still listening after application crash

问题描述

我在Windows 2008x64上的一个我的C + +应用程序有一个问题（相同的应用程序运行正常在Windows 2003x64）。

I'm having a problem with one of my C++ applications on Windows 2008x64 (same app runs just fine on Windows 2003x64).

在崩溃后，甚至有时在正常关机/重新启动周期后，使用端口82上的套接字需要接收命令时出现问题。

After a crash or even sometimes after a regular shutdown/restart cycle it has a problem using a socket on port 82 it needs to receive commands.

查看netstat我看到套接字在应用程序停止后仍然处于监听状态超过10分钟（该进程绝对不再运行）。

Looking at netstat I see the socket is still in listening state more than 10 minutes after the application stopped (the process is definitely not running anymore).

  TCP    0.0.0.0:82             LISTENING

我试图将套接字选项设置为REUSEADDR，但据我所知，只有影响重新连接到处于TIME_WAIT状态的端口。无论哪种方式，这种变化似乎没有任何区别。

I tried setting the socket option to REUSEADDR but as far as I know that only affects re-connecting to a port that's in TIME_WAIT state. Either way this change didn't seem to make any difference.

int doReuse = 1;
setsockopt(listenFd, SOL_SOCKET, SO_REUSEADDR,
           (const char *)&doReuse, sizeof(doReuse)); 

任何想法我可以做些什么来解决或至少避免这个问题？

Any ideas what I can do to solve or at least avoid this problem?

编辑：

做了netstat -an，但这是我得到的：

Did netstat -an but this is all I am getting:

  TCP    0.0.0.0:82             0.0.0.0:0              LISTENING

对于netstat -anb，我得到：

For netstat -anb I get:

  TCP    0.0.0.0:82             0.0.0.0:0              LISTENING
 [System]

我知道正常关闭，如果应用程序崩溃由于某种原因，我仍然需要能够重新启动它。相关应用程式使用内部使用Windows Sockets API的内部程式库。

I'm aware of shutting down gracefully, but even if the app crashes for some reason I still need to be able to restart it. The application in question uses an in-house library that internally uses Windows Sockets API.

EDIT：

显然没有这个问题的解决方案，所以对于开发我将使用代理/工具来解决它。非常感谢所有的建议。非常感谢。

Apparently there is no solution for this problem, so for development I will go with a proxy / tool to work around it. Thanks for all the suggestions, much appreciated.

推荐答案

如果这只是在调试时伤害你，使用 tcpview 从sysinternals的人强制套接字关闭。我假设它在你的平台上工作，但我不确定。

If this is only hurting you at debug time, use tcpview from the sysinternals folks to force the socket closed. I am assuming it works on your platform, but I am not sure.

如果你对任何套接字进行阻塞操作，不要使用不确定的超时。这可能在我的经验中在多处理器机器上引起奇怪的行为。我不知道什么Windows服务器操作系统，但是，它是2003年之前的一个或两个版本的服务器。
代替不确定的超时，使用30到60秒的超时，然后重复等待。如果你使用重叠的IO和IOCompletion端口，这也适用。

If you're doing blocking operations on any sockets, do not use an indefinite timeout. This can cause weird behavior on a multiprocessor machine in my experience. I'm not sure what Windows server OS it was, but, it was one or two versions previous to 2003 Server. Instead of an indefinite timeout, use a 30 to 60 second timeout and then just repeat the wait. This goes for overlapped IO and IOCompletion ports as well, if you're using them.

如果这是一个应用程序，供其他人使用，祝你好运。 Windows使用套接字时可以是纯粹的混蛋...

If this is an app you're shipping for others to use, good luck. Windows can be a pure bastard when using sockets...

这篇关于Socket在应用程序崩溃后仍然侦听的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！