From owner-freebsd-questions Sat Aug 21 16:43:18 1999 Delivered-To: freebsd-questions@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id D1FF914CAC for ; Sat, 21 Aug 1999 16:43:14 -0700 (PDT) (envelope-from rfg@monkeys.com) Received: from monkeys.com (LOCALHOST [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id QAA01540; Sat, 21 Aug 1999 16:01:09 -0700 To: Brian Somers Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Passing file descriptors via UNIX domain sockets In-reply-to: Your message of Sat, 21 Aug 1999 22:50:22 +0100. <199908212150.WAA06688@keep.lan.Awfulhak.org> From: "Ronald F. Guilmette" Date: Sat, 21 Aug 1999 16:01:09 -0700 Message-ID: <1538.935276469@monkeys.com> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199908212150.WAA06688@keep.lan.Awfulhak.org>, you wrote: >One caveat (I had to learn the hard way!) is that you *must* also >pass some data in the oivec. If you don't, the descriptor isn't >passed. I am _not_ passing any data in the iovec now, and yet the file descriptor seems to come across just fine... at least on FreeBSD. I'll try passing some data along with the fd on Linux and see if that helps any. >Also, make sure you get an acknowledgement from the other >side before closing the descriptor. If you close it while it's in >transit, the other side will receive a closed descriptor as the open >count isn't incremented as it's passed (in case the other side never >does a recvmsg()). Yes. I _did_ notice that sort of handshake going on in the BSD ppp code, where it is passing fds. So I implemented that too, going on the assumption that (as you said) if the fd is in transit, and the sender closes it before it makes it to the receiver, that it may just be closed for good, and that the receiver may then just end up receiving a closed (and useless) fd. I was kinda wondering about that possibility while I was looking at the fd passing example in my (first edition) Stevens' book. In the example in the book, the sending process *didn't* seem to wait to make sure that the receiver actually received the fd before the sender exited! That looked damed suspicious to me, so I was already on my guard about the possible need for the sender to wait for some sort of ACK back from the received (as happens in the BSD ppp code) when I started to code up my little fd-passing test programs. I'll bet that *this* (i.e. failure to wait for an ACK from the receiver) bites a lot of people... especially anyone who is just looking at the (first edition) Stevens book when trying to figure out how to do this stuff. But then again, anybody who is *just* looking at that, and who is trying to make this stuff work (as I was) won't be able to get it anywhere near to working with the new coding idiom that you have to use with the new (Free)BSD kernel networking code that supports this (fd passing) stuff anyway. Thank God for source code! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message