On Sat, Apr 01, 2017 at 10:57:48AM +0000, Luke Small wrote: > Or put in the man page to "Google it!" Lol > On Sat, Apr 1, 2017 at 5:33 AM Otto Moerbeek <[email protected]> wrote: > > > On Sat, Apr 01, 2017 at 12:50:46AM -0700, Philip Guenther wrote: > > > > > On Sat, 1 Apr 2017, Otto Moerbeek wrote: > > > > On Sat, Apr 01, 2017 at 01:20:25AM -0500, Luke Small wrote: > > > > > > > > > Here are two programs. They both fork two clients that try to connect > > > > > on port 'portno' that is listened to in main(). It spawns a receive > > > > > that receives passed file descriptors passed from main(). It passes a > > > > > file descriptor of the client connection to receive twice. > > > > > server_sample0.c uses the man page code. server_sample.c uses my > > > > > example. the former fails to pass the file descriptor on the second > > > > > try. the latter succeeds both times. I don't think you have any more > > > > > questions. > > > > > > > > Well, it took some effort to get this out of you. > > > > > > > > It seems that a problem exists indeed. It happens when the iovec data > > is > > > > not filled in, as the example uses. recv(2) only returns the number of > > > > bytes read from the iovec, so there seems to be some confusion about a > > > > failed read and a read of zero bytes. I'll check with the standard what > > > > is supposed to happen when only auciliary data is sent. > > > > > > Well, it's not a failed read: recvmsg() returns 0, not -1. > > > > Indeed, my wording was wrong. Still, on the receving side, you like to > > dsitinguish beteen -1, 0 (EOF) and a real message, I suppose. > > > > > > > > The issue is that in the kernel socket receive buffer, control messages > > > from a single send are always followed by a normal data buffer. In > > kernel > > > terms, an MT_CONTROL mbuf chain is always followed by an MT_DATA mbuf > > > chain...even when there's no data sent. In that case, the MT_DATA mbuf > > > has length zero. > > > > > > This works fine on the sending side, but when recvmsg() finishes with the > > > control messages and gets to the data buffer, it thinks it's done, as the > > > caller requested that nothing be copied out and it doesn't remove the > > > zero-length MT_DATA mbuf, leaving it at the head of the socket buffer. > > > Succeeding calls see no control messages at the start and then again do > > > nothing to the data buffer. > > > > > > Note this is specific to SOCK_STREAM sockets: the boundary preserving > > > behavior of SOCK_DGRAM and SOCK_SEQPACKET mean it doesn't happen there. > > > > > > To avoid this, the application doesn't need to *send* any data, it just > > > needs to always accept at least one byte of data when calling recvmsg(). > > > Even if there's no data there, that acceptance of more than zero bytes of > > > data will let recvmsg() peel off the zero-length MT_DATA mbuf from the > > > send. > > > > > > > > > I guess the questions then are > > > 1) is this a bug? can it be fixed? and > > > 2) if not, should it be documented and where? > > > > > > On the latter, I'm not convinced the example code in CMSG_DATA(3) is the > > > place to do so. If we deleted all the EXAMPLES sections from manpages > > > they should be merely more difficult to understand, not incomplete. More > > > importantly, this behavior isn't related to the CMSG_* macros at all, but > > > rather to recvmsg(2) itself. Maybe a cavest there? > > > > I'd say, it's a bug, but if it cannot be fixed for some reason, > > recvmsg(2) should document this *and* the example in CMSG_DATA(3) should > > show the proper use. > > > > > > -Otto > > > >
Relevant to this discussion (thangs jca@ fro pointing this out!) is this old thread: http://marc.info/?l=openbsd-tech&m=140008704815878&w=2 The table in one of the messages (look at in raw mode) show that many operating systems have problems with this case. So a CAVEAT entry in recvmsg(2) and the example showing the portable way of doings things are still needed, whether the bug will be fixed in OpenBSD or not. As I read it, sendmsg(2) with no data is fine according to the standard: quote from http://pubs.opengroup.org/onlinepubs/9699919799/ : The msg_iov and msg_iovlen fields of message specify zero or more buffers containing the data to be sent. msg_iov points to an array of iovec structures; msg_iovlen shall be set to the dimension of this array. In each iovec structure, the iov_base field specifies a storage area and the iov_len field gives its size in bytes. Some of these sizes can be zero. The data from each storage area indicated by msg_iov is sent in turn. Alas, the standard is not clear about a recvmsg(2) call with no data buffer space. -Otto
