SO_LINGER 和关闭套接字(WINSOCK)

发布于 2024-09-01 13:59:35 字数 313 浏览 3 评论 0原文

我正在编写一个多线程winsock应用程序,并且在关闭套接字时遇到一些问题。 首先,同时打开的套接字数量是否有限制?假设一次有 32 个插座。

我在其中一个套接字上建立了连接,并传递信息,一切顺利。 问题是当我断开套接字然后重新连接到同一目标时,我在 SYN 之后从服务器收到 RST。 我没有服务器应用程序的代码,所以我无法调试它。

当我使用 SO_LINGER 并在每个会话结束时发送一个 RST 标志时 - 它起作用了。 但我不想以这种方式结束我的联系。 当不使用 SO_LINGER 时,发送了 FIN 标志,但似乎连接并未真正关闭。

有什么帮助吗? 谢谢

im writing a multithreaded winsock application and im having some issues with closing the sockets.
first of all, is there a limit for a number of simultaneously open sockets? lets say like 32 sockets all in once.

i establish a connection on one of the sockets, and passing information and it all goes right.
problem is when i disconnect the socket and then reconnect to the same destination, i get a RST from the server after my SYN.
i dont have the code for the server app so i cant debug it.

when i used SO_LINGER and it sent a RST flag at the end of each session - it worked.
but i dont want to end my connections this way.
when not using SO_LINGER a FIN flag was sent but it seems the connection was not really closed.

any help?
thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

绝不服输 2024-09-08 13:59:35

在 Unix 上,每个进程有一个文件描述符限制 - 我猜在 Windows 上它是“句柄”。

您可能正在使用 bind() 将您的客户端套接字连接到固定端口。这可能是服务器拒绝您后续连接的原因。尝试普通的临时端口。

On Unix there's a file descriptor limit per process - I'm guessing on Windows it's "handles".

You are probably bind()-ing your client socket to a fixed port. That might be the reason the server is rejecting your subsequent connection. Try normal ephemeral ports.

随遇而安 2024-09-08 13:59:35

首先,我同意尼古拉的观点,你是否绑定了客户端套接字?

如果是这样,听起来服务器端的套接字仍处于 TIME_WAIT 状态,并且正在丢弃新的连接尝试。通过绑定客户端套接字,您将强制服务器尝试重用当前处于 2MSL 等待期间的完全相同的连接,此时无法重用它,因此您将看到您所看到的内容。通常不需要绑定客户端端口,停止这样做,您的问题可能就会消失。

其次,是的,Windows 平台上的打开套接字数量是有限制的,但它们与资源相关,而不是某些硬编码的数字。

每个打开的套接字都使用一些“非分页池”内存,并且套接字上的每个挂起的读或写请求也可能同时使用“非分页池”,并且在 I/O 期间将内存页锁定在内存中(对可锁定的页数)。也就是说,在 Vista 及更高版本上,比早期版本的 Windows 上可用的“非分页池”要多得多,即便如此,我还是设法在规格相当低的 XP 机器上实现了超过 70,000 个并发活动连接(请参见此处:http://www.lenholgate.com/blog/2005/11 /windows-tcpip-server-performance.html)。请注意,您可以建立的出站连接数量有一些单独的限制(您可能更感兴趣),但默认情况下约为 4000 个,可以通过设置 MAX_USER_PORT 进行调整,请参阅这里: 最大并发 TCP 数量/ IP 连接 - Win XP SP3 了解更多详细信息。

Firstly, I agree with Nikolai, are you binding your client socket?

If so it sounds like the socket on the server side is still in TIME_WAIT and is discarding the new connection attempt. By binding the client socket you're forcing the server to try and reuse the exact same connection that is currently in the 2MSL wait period, it can't be reused at this point in time and so you're seeing what you're seeing. There's usually no need to bind the client port, stop doing it and your problem will likely go away.

Secondly, yes, there are limits to the number of open sockets on Windows platforms but they're resource related rather than some hard coded number.

Each open socket uses some 'non paged pool' memory and each pending read or write request on a socket is also likely to use both 'non paged pool' and have pages of memory locked in memory during I/O (there's a limit to the number of pages that can be locked). That said on Vista and later there's much more 'non paged pool' available than on earlier versions of Windows and even then I've managed to achieve more than 70,000 concurrent active connections on a pretty low spec XP box (see here: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html). Note that there are some separate limits on the number of outbound connections that you can establish (which is more likely to be of interest to you) but that's around 4000 by default and can be tuned by setting MAX_USER_PORT see here: Maximum number of concurrent TCP/IP connections - Win XP SP3 for more details.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文