Unix socket, SOCK_SEQPACKET vs SOCK_DGRAM

Question

It seems there's atleast 3 different local/unix socket types (AF_UNIX) , SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET.

While I know that a SOCK_STREAM gives you a bi-directional byte stream, like TCP or a bidirectional pipe, and the other two gives you a messge/packet API, what's the difference between a unix socket of SOCK_DGRAM and SOCK_SEQPACKET ?

As these are local only, I can't think of a good reason someone would implement SOCK_DGRAM in a manner it could reorder packets.

Also, does SOCK_DGRAM/SOCK_SEQPACKET employ flow control, or can messages be dropped in case of slow readers ?

Answer 1

Here is a good article on the intended use case for SOCK_SEQPACKET, the fact that it's not really available in the IP protocol families, and how you can get the same thing with existing TCP semantics:

http://urchin.earth.li/~twic/Sequenced_Packets_Over_Ordinary_TCP.html

Note that SOCK_SEQPACKET is much closer in behavior to SOCK_STREAM than to SOCK_DGRAM.

Citing from the referenced website:

The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type, and is also connection-oriented. The only difference between these types is that record boundaries are maintained using the SOCK_SEQPACKET type. A record can be sent using one or more output operations and received using one or more input operations, but a single operation never transfers parts of more than one record. Record boundaries are visible to the receiver via the MSG_EOR flag in the received message flags returned by the recvmsg() function. It is protocol-specific whether a maximum record size is imposed.