我正在编写一个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()创建一个通信端点并返回一个文件指向该端点的描述符。文件描述符成功调用返回的将是编号最低的文件描述符当前未为进程打开.
我理解一个文件描述符是"随机"赋值,只是发现它在以这种或那种方式运行时总是返回相同的数字。
这是值得担心的吗?这是否表明我移植的代码已经不能像预期的那样工作,并且继续前进将最终产生意想不到的结果?
文档说:
调用成功返回的文件描述符将是当前未为进程打开的编号最低的文件描述符。
所以如果你的进程打开了文件描述符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中文件描述符通常的分配方式。