Accept() 如何确定返回哪个整数？
在 Linux 系统上使用 C 套接字库...
当我调用 accept( ) 时，它总是返回一个整数。 STDIN 是 0。通常我的第一个接受调用返回 3。之后它们会递增。
我想知道; accept( ) 如何确定下一个整数是哪个？如果在另外 2 次 accept( ) 调用之后，我将 3、4 和 5 个分配给已连接的客户端；当4断开连接时会发生什么？下一个整数是 4 还是 6？
如果有人能阐明这一点，我肯定会很感激。
Using the C sockets library on a Linux system...
When I make a call to accept( ) it always returns an integer. STDIN is 0. Usually my first accept call returns 3. They increment after that.
I was wondering; how does accept( ) determine which integer is next? If, after 2 more accept( ) calls, I have 3, 4, and 5 assigned to connected clients; what happens when 4 disconnects? Is the next integer 4 or is it 6?
If someone could shed some light on this I sure would appreciate it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
它使用下一个当前未打开的文件描述符，与
open()和其他返回文件描述符的系统调用相同；dup2()是该模式的一个例外。（例如，文件描述符可能未打开，但如果它是尚未完全清理的网络连接的一部分，则可能仍然无法重用。）（更新：删除文本恢复原始版本的答案 如果文件描述符已关闭，则可以重新使用套接字地址，因为 TCP/IP 中的 FIN-WAIT 状态可能会出现问题 - 但套接字地址是可用的。不是文件描述符。）如果打开描述符 1-5，然后关闭 4，则下一个类似打开的操作将返回 4。
可能存在安全意识系统，但这种情况不是模式，但可能性不大。一个原因是有正确的代码来处理 I/O 重定向，该代码依赖于关闭标准输入（文件描述符 0）以及重用文件描述符的下一个类似打开的操作；重复标准输出（文件描述符 1）。
It uses the next currently unopen file descriptor, the same as
open()and other system calls that return file descriptors;dup2()is something of an exception to the pattern.(A file descriptor might not be open but might still be unavailable for reuse if it was part of a network connection that has not been completely cleaned up yet, for example.)(Update: struck out text reinstates original version of answer. If a file descriptor is closed, it is available for reuse. There might be issues with reusing a socket address because of FIN-WAIT states in TCP/IP - but a socket address is not the file descriptor.)If you have descriptors 1-5 open, then close 4, the next open-like operation will return 4.
There might be security-conscious systems where this is not the pattern, but it is unlikely. One reason is that there is correct code for handling I/O redirection that relies on closing standard input (file descriptor 0) and the next open-like operation reusing the file descriptor; repeat for standard output (file descriptor 1).
简短的答案是，不要指望接受以任何预期的顺序给你整数。不管你认为多么容易，只要它确实做到了，它就会有所作为。
Accept 返回的实际上是内核资源的“描述符”，它将将该描述符连接到读写、关闭、查找（如果有能力）所需的正确驱动程序。可用描述符池是有限的，因此当您关闭套接字时，其描述符将返回到池中并可以重用。
The short answer is, do NOT count on accept giving you integers in any expected order. No matter how seductively easy you think it would make things if it did.
What accept is returning is actually a 'descriptor' to a kernel resource that will connect that descriptor to the proper drivers necessary to read and write, close, seek(if capable). The pool of available descriptors is limited, so when you close a socket its descriptor goes back into the pool and can be reused.
它返回接受套接字的文件描述符：
这为您提供了一个数值，您可以在各种文件操作中使用什么值，并在幕后决定。
It's returning a file descriptor for the accepted socket:
This gives you a numeric value that What value that you can use with various file operations, and is decided behind the scenes.