The current implementation verifies that the sock passed is a stream socket. This limitation appears to be arbitrary and is limiting.

* An AF_UNIX SOCK_DGRAM server socket becomes readable when one can accept(2) it. Just like SOCK_STREAM.
* One could provide a different factory to create a reader/writer to use a SOCK_DGRAM socket (but most likely nothing special is needed)
* A connected AF_UNIX SOCK_DGRAM socket will work with normal read/write messages just like SOCK_STREAM.

AF_UNIX, SOCK_DGRAM is interesting because it provides a reliable transport for messages. This avoids having to write message segmentation or packing messages in any kind of envelope.

SOCK_DGRAM is never reliable, even for AF_UNIX.  It might appear reliable to your test code, but there's no guarantee for that under any OS in Posix standard AFAIK.

Could you please tell me which exact posix document and paragraph says that?

In Linux sending can fail but once sendmsg worked the message is enqueued on the other socket (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/unix/af_unix.c?id=110af3acb8cfd79dcb5676a01e07cb2b6afa4c04#n1626).

In FreeBSD (http://fxr.watson.org/fxr/source/kern/uipc_usrreq.c?v=FREEBSD10#L911) it looks similar. If the mbuf can't be put into the recvq of the remote socket.. an error will be returned.

What about SEQPACKET support?

Hm, maybe I'm mistaken here, but I have no time right now to confirm.

I'll reopen the issue so that we can consider this (and especially SEQPACKET) for 3.8.  Sorry for insta-reject :)