linux socket文件描述分配有多随机？答案

【问题标题】：How random is a linux socket file description assignment?linux socket文件描述分配有多随机？
【发布时间】：2021-12-06 07:53:49
【问题描述】：

我正在编写一个 C# 应用程序，在 Linux 中使用 netlink 协议（通过 libnl 库）与我的无线网卡进行通信。

基本上我在模仿iw 的功能。在这个初始状态下，我想确保初始移植调用结果与调试真实 linux 应用时的结果相同。

它们是 - 除了我使用nl_socket_get_fd 获取套接字文件描述符得到的结果。调试应用程序始终返回值为 3 的文件描述符，而我的 c# 应用程序外部调用 nl_socket_get_fd 始终返回 26（即使在系统启动后）。

我记得不久前我也尝试过这样做 - 但模仿 iwlist 代替（在注意到它现在已被弃用之前）。调试也总是返回 3（最终调用 libc 的 socket 函数），而调试我的 C# 端口总是返回 19。

Socket 的手册页说

socket() 创建一个通信端点并返回一个文件指向该端点的描述符。 文件描述符成功调用返回的将是编号最小的文件当前没有为进程打开描述符。

我知道文件描述符是“随机”分配的，只是发现它在以这种或那种方式运行时总是返回相同的数字很可疑。

这有什么好担心的吗？这是否表明我移植的代码已经无法按预期工作，继续前进最终会产生意想不到的结果？

【问题讨论】：

它说它将返回尚未使用的最小数字。因此，可能在 iw 运行时使用 0 1 和 2，而在 C# 运行时使用更多（例如加载 C# 库）...
所以我认为假设我的系统每次都使用相同的 N 个进程启动是正确的，如果我总是在不打开任何其他程序的情况下进行调试，我应该总是得到相同的文件描述符 - 并且 - 调试真正的应用程序与我移植的应用程序 - 永远不会返回相同的文件描述符？
与其他进程无关，与你的进程打开的文件描述符的数量有关。
我正在尝试详细说明有关分配自然文件描述符的“确定性”声明。对，与打开的进程无关，而是与打开的文件描述符的数量（由现有进程）有关。所以，换个说法：假设在启动我的系统后的任何给定时间打开的文件描述符的数量，而不启动任何其他程序，似乎是安全的 - 应该是恒定的（对于 any这可能不是真的> 给定时间，可能会有一些操作可能会改变这一点，但理论上听起来一般是正确的？

【解决方案1】：

文档说：

成功调用返回的文件描述符将是当前未为进程打开的编号最小的文件描述符。

因此，如果您的进程有打开的文件描述符 0、1 和 2，但没有 3，它将返回 3。

如果您的进程有打开的文件描述符 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20、21、22、23、24 和 25，但不是 26，它将返回 26。

这是在 Linux 中通常分配文件描述符的方式。

【讨论】：

如果文件描述符 25 稍后被释放，则将分配下一个，尽管 26 已经在使用中。
@Veverke 是的。如果 0、1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17、18、19、20、21、22、23 和24 是开放的，但不是 25，它会返回 25。
不，我的意思是 - 如果打开 1,2,3 - 仅此而已，然后释放 2。下一个要分配的文件描述符是 2，而不是 4。只是为了完整性（并确保我的理解是正确的）
@Veverke 是的。因为 0 和 1 是开放的，但不是 2，所以它会返回 2
顺便说一句 - 为了这个例子，你能不能让描述符列表更小，而不是 1-26 ？ :-)