为什么我们不能通过描述符传递描述符作为正常数据意味着我们发送,通过unix域套接字recv其他数据？
我能够理解这个过程.请解释一下这本书中给出的方法.
另外,在那本书中,在read_fd()函数中,他声明了union正确对齐msghdr结构.工会如何协调一致？为什么需要对齐？
Why cant we pass a descriptor as
normal data means as we do send,recv
for other data through unix domain
sockets?
因为打开的文件描述符不能作为字节流有效地序列化.
虽然文件描述符实际上只是整数,但它们由内核(按进程方式)映射到内核数据结构,这些数据结构描述打开的’文件’的细节(它是’普通’文件吗？是一个块/ character special device？是某种网络套接字吗？是匿名管道吗？等等.文件描述符传递的目标是在一些其他(可能不相关的)进程中创建一个新的文件描述符(可能带有一些其他整数值),该进程映射到与发送进程中的原始描述符相同的内核内部数据结构.
您必须经历的这些操作只是访问此功能的“API”(请注意,基于System V的Unix系统有一种基于STREAMS的文件描述符传递的替代方法,它使用不同的“API”).我不知道历史,但我猜想通过“API”的BSD文件描述符的“复杂性”是由于将功能强加到预先存在的sendmsg(2)/ recvmsg(2)API中.
How union makes it aligned? and why
alignment is required?
我没有在我面前实施UNP,但使用工会并不是唯一的方法. Kragen Sitaker’s portlisten example使用CMSG_ *宏而不是联合.我们的想法是确保< struct msghdr> .msg_control指向< struct cmsghdr>.
