On Fri, May 27, 2011 at 01:20:04PM -0400, der Mouse wrote: > > I'm not sure what happens for blocking datagram sockets. > > The historical practice is that they're "best effort": writing never > blocks. Some conditions responsible for packet drop are reflected in > the write()/send()/etc return value; others aren't - though I think for > AF_LOCAL they're all the former. Blocking on SOCK_DGRAM matters only > when trying to read when there's nothing there. > > Is that how it _should_ be? That's debatable. But if you make > SOCK_DGRAM writes block without some kind of explicit request (like a > setsockopt), you will break a fair bit of code.
Yeah, it's worse than that. There is at least one widely deployed implementation out there where AF_LOCAL, SOCK_DGRAM even reorders datagrams -- "just like real UDP!". Oh, and sometimes it used to duplicate them, but I guess that was an unintentional bug. AF_LOCAL, SOCK_SEQPACKET offers an opportunity to establish reasonable semantics that would be a lot more useful for many of the users of local SOCK_DGRAM sockets. I'm all for it. What do the SCTP implementations out there in the world use now? SOCK_DGRAM, SOCK_SEQPACKET, or something else? That might be the only other prior ue of the seqpacket sockets.
