wcf - 在其所属进程退出后，如何释放 "daemon"TCP 端口监听器？

Question

背景

我有一个在 net.tcp 端口 667 上监听的 .net 4.0 WCF 应用程序。(Windows 7 机器)
在某些时候，应用程序会异常退出(例如，用户终止进程)。
现在发生了一件奇怪的事情:端口保持打开状态。当用户重新启动应用程序时，它无法监听该端口，因为它已被使用。

奇怪的是，即使拥有的进程被杀死，操作系统也没有关闭端口，甚至在几个小时后也没有。

以下是一些观察结果:

• 在 TcpView 上，进程是 <non-existent> ，PID 属于旧的(被杀死的)进程，状态为 LISTENING .本地地址是我的机器，同时有IPV4和 IPV6该端口上的听众。
• TcpView 上的“关闭连接”和“结束进程”操作对该端口没有影响。
• Process Explorer 不显示旧的(终止的)进程。我尝试搜索 PID 或端口的句柄，但一无所获。
• 运行时 netstat -a -b -n -o涉及的可执行文件显示为System本地地址是0.0.0.0 .其他信息同TcpView。

我发现关闭该端口的唯一方法是系统重启...

问题

1. 有没有办法配置 WCF net.tcp 服务主机监听器，以避免在进程不正常地存在后逗留？
2. 有没有办法以编程方式关闭该端口？如果有，我的应用程序可以先关闭该端口，然后再尝试收听它。
3. 是否有可以关闭此类“守护程序”端口的实用程序？ (因为 TcpView 不能这样做)
4. 这是操作系统错误吗？操作系统不应该跟踪此类“守护进程”监听器并在进程存在后关闭它们吗？

Answer 1

Is there a way to configure the WCF net.tcp Service Host listener to avoid lingering after the process exists ungracefully?

不，至少你不应该使用，但有一种方法可以告诉它在重新启动时重用套接字地址，这就没有必要了。

Is there a way to programatically close that port? If there is, my application could first close that port before trying to listen to it.

没有。只有打开端口的应用程序才能关闭它。

Is there a utility that could close such "daemon" ports? (since TcpView cannot do that)

不，见上文。

Is this an OS bug? Shouldn't the OS keep track of such "daemon" listeners and close them once the process exists?

当进程退出时，包括 TCP 端口在内的所有进程资源都应该被释放。在 TCP“已建立”端口的情况下有一个异常(exception)，出于 TCP 安全原因，它会停留几分钟。

听起来好像有一个子进程继承了仍然活跃的套接字。