當我們想要將描述符從子進程傳遞到進程時，UNP V1（Unix網絡編程V1）指定了一個複雜的過程，首先創建msghdr結構體然後創建一些東西等。使用unix域套接字傳遞的描述符
爲什麼我們不能像普通數據那樣傳遞描述符，就像我們發送一樣，通過unix域套接字接收其他數據？ 我能夠理解這個過程。請解釋該書中給出的方法。
而且，在這本書中，read_fd（）函數，他宣稱工會正確對準指向msghdr結構。工會如何使其一致？以及爲什麼需要對齊？
爲什麼不能傳遞了一個描述符 正常的數據，作爲我們做派，recv的 其他數據通過Unix域套接字 ？
因爲打開的文件描述符不可用作序列化字節流。
雖然文件描述符實際上只是整數，它們是由內核（在每進程方式）來說明該打開的「文件」的細節內核內部數據結構映射（是這正常'文件？是塊/字符特殊設備？它是某種網絡套接字嗎？是匿名管道嗎？等等）。文件描述符傳遞的目標是在映射到與發送進程中的原始描述符相同的內核內部數據結構的其他一些（可能不相關的）進程中創建新的文件描述符（可能具有其他整數值）。（注意，基於System V的Unix系統有一個基於STREAMS的文件描述符傳遞的替代方法，它使用不同的「API」 「）。我不知道歷史，但我猜測BSD文件描述符通過「API」的「複雜性」是由於將功能鎖定在已有的sendmsg(2)/recvmsg(2) API中。
聯合如何讓它對齊？以及爲什麼要求 對齊？
我沒有在我面前實施UNP，但使用聯合並不是唯一的出路。 Kragen Sitaker's portlisten example使用CMSG_ *宏而不是聯合。這個想法是確保<struct msghdr>.msg_control指向。
沒有該書的副本，我們很難向您解釋本書中給出的方法。
有幾種通用技術將文件描述符從父進程傳遞到子進程。如果您知道文件描述符前啓動子：
如果你只知道文件描述符發射後不管孩子，就需要那麼某種形式的IPC：
這聽起來像你正在閱讀介紹的最後一個選項的書上。向孩子發送消息時，您可以自由選擇您要發送的任何數據的表示形式。如果你發送一個文件描述符（一個整數）而沒有其他信息，那麼你可以自由選擇幾乎任何表示。整數的ASCII表示可能是合適的，或者可以發送代表32位整數的四個字節。
再次，這是很難猜測，爲什麼這本書的作者是做事情會是這樣的，不知道有什麼方法實際上是。