On Mon, Mar 14, 2011 at 4:36 PM, Paolo Bonzini <bonz...@gnu.org> wrote: > On 03/14/2011 04:19 PM, Bastien ROUCARIES wrote: >>> >>> > But that was a different problem. That was not related to >>> > sendfd/recvfd. >>> > >>> > However, there are cases in which you want to send a file descriptor >>> > as >>> > out-of-band messages on a stream socket, and libvirt also has one of >>> > those. >> >> Does sending as oob data process id will fall on the previous trap on >> SOCK_STREAM ? > > I was using "out-of-band" as a generic term, so SCM_RIGHTS also falls under > the definition of "out-of-band". > >> oob are not implemented for unix so it will work under windows emulation > > While using TCP out-of-band data would be an interesting solution for > Windows, UDP doesn't have out-of-band data. So, if sendfd/recvfd is going > to be limited to SOCK_DGRAM, using out-of-band data for Windows is not going > to work.
Could we know from fd if it is a udp or tcp socket ? - if tcp send as OOB - if udp send normally > On the other hand, if sendfd/recvfd is limited to SOCK_DGRAM, it is okay > under Windows to send the handle normally as a UDP datagram through > send/recv (your original plan). > > The limitation of sendfd/recvfd to SOCK_DGRAM is perfectly sane---I just > wanted to point out that it would not be possible for libvirt to use sendfd, > at least in one of the two scenarios where it is currently using SCM_RIGHTS. > > Paolo > Bastien
