You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Unix域套接字带外传UnixRights文件描述符收发数值不同原因问询

问题原因解答
  • Unix域套接字传递文件描述符时,传输的不是文件描述符的数值本身,而是对应的内核文件表项引用。每个进程的文件描述符表是独立的,内核会在接收方进程的文件描述符表中分配一个空闲的数值来关联这个传递过来的文件,所以两边数值不一样是完全正常的行为,不是数据传输错误。你遇到的场景就是进程A的fd为9,进程B中分配到的空闲fd为8,对应出现了第13字节的差异。
  • 你调用WriteMsgUnix的参数存在逻辑错误,该方法的签名是func (c *UnixConn) WriteMsgUnix(b, oob []byte, addr *UnixAddr) (n, oobn int, err error),第一个参数是普通业务数据的缓冲区,第二个才是带外(辅助)数据的UnixRights。你现在两个参数都传了rights,虽然当前场景下不影响文件描述符的传递,但会额外发送多余的普通数据,建议修正为:
// 不需要发送普通业务数据时,第一个参数传nil或者空切片即可
n, oobn, err := uc.WriteMsgUnix(nil, rights, nil)
  • 不要直接解析oob的原始字节来提取文件描述符,标准库提供了专门的解析方法syscall.ParseUnixRights,用法示例:
_, oobn, _, _, err := uc.ReadMsgUnix(buf, oob)
if err != nil {
    // 处理错误逻辑
}
fds, err := syscall.ParseUnixRights(oob[:oobn])
if err != nil {
    // 处理错误逻辑
}
// fds[0] 就是进程B中可用的目标文件描述符,也就是你场景里的8

内容的提问来源于stack exchange,提问作者杨苏杭

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.10.17 11:24:10