c# - Winsock tcp/ip 套接字监听但连接被拒绝，竞争条件？

Question

这涉及到两个自动单元测试，每个单元测试都启动一个 tcp/ip 服务器，创建一个非阻塞套接字，然后在 select() 上循环 bind()s 和 listen(s) 为连接和下载一些客户端数据。

问题是它们在单独运行时可以完美运行，但作为测试套件运行时，第二个测试客户端将无法连接 WSACONNREFUSED...

除非

他们之间有几秒的Thread.Sleep()??!!

有趣的是，每 1 秒有一次重试循环，用于在任何失败后进行连接。所以第二个测试循环一段时间，直到 10 分钟后超时。

在此期间，netstat -na 显示服务器套接字处于 LISTEN 状态的正确端口号。那么如果是listen状态呢？为什么它不接受连接？

在代码中，有日志消息显示 select 甚至从未准备好读取套接字(这意味着当它应用于监听套接字时准备好接受连接)。

显然，这个问题一定与完成一个测试(即套接字两端的 close() 和 shutdown())和下一个测试之间的某种竞争条件有关。

如果重试逻辑允许它在几秒钟后最终连接，这就不会那么糟糕了。然而，它似乎变得“糊涂了”，甚至不会重试。

但是，由于某些奇怪的原因，监听套接字说它处于 LISTEN 状态，即使一直拒绝连接也是如此。

所以这意味着实际上是 Windoze O/S 捕获了 SYN 数据包并返回了一个 RST 数据包(这意味着“连接被拒绝”)。

我唯一一次看到此错误是在代码出现问题导致数百个套接字卡在 TIME_WAIT 状态时。但这里不是这种情况。 netstat 仅显示大约十几个套接字，在任何给定时刻只有 1 或 2 个处于 TIME_WAIT。

请帮忙。

Answer 1

根本的问题是关闭套接字，一个线程试图读取任何剩余的字节。这是作为一个单独的线程完成的，该线程将套接字的读取端保持打开固定的毫秒时间，同时反复尝试读取任何数据。

该逻辑已被替换为更智能地读取任何数据并在读取返回 0 时正确关闭。因此它关闭得更快。

所以原来是我自己的代码中socket关闭不当

感谢大家的帮助!