67

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 ?

Improve this question
2
  • IIRC, SOCK_DGRAM will give you one message at a time, while SOCK_SEQPACKET(for protocols which support it) will allow you to read multiple datagrams at a time, but always give atomic reads of datagrams, vice SOCK_STREAM where you need to parse the message boundaries yourself. Commented Apr 11, 2012 at 12:11
  • 2
    Just a comment SOCK_SEQPACKET is used in AX.25 (Ham radio protocol) see for example stackoverflow.com/questions/19040205/… Commented Jul 10, 2014 at 16:22

5 Answers 5

Reset to default
33

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

It does talk more about TCP/IP than PF_UNIX (PF_LOCAL) sockets though.. So far it seems the only real difference between a SOCK_SEQPACKET and SOCK_DGRAM local socket is that a SOCK_SEQPACKET socket is connection oriented, but i'm still not sure..
Well, this answer is wrong. The question asks specifically about PF_UNIX, and while the ideal SOCK_SEQPACKET would be one abstraction level higher than SOCK_STREAM (providing messages boundaries over it), the implementations are not so idealistic. According to this, PF_UNIX implementations are very much liker SOCK_DGRAM, except for... well, I don't really know, that is why I came into this page, and no answer seems satisfactory. This answer applies only to more elaborated network protocols that implements SOCK_SEQPACKET as supposed to be.
@lvella: The link I cited in my answer not only explains how to emulate SOCK_SEQPACKET on TCP (which is not relevant to OP's question) but also the motivations of SOCK_SEQPACKET, which I believe are one of the main topics OP was asking about.
@R.. The problem is, whatever is the motivation for SOCK_SEQPACKET, that is not how it works on AF_UNIX, and I still don't why it exists, since the implementation lacks precisely what should differentiate it from SOCK_DGRAM (message boundary markings that are independent from the low-level datagram).
15

I think the main difference here is that SOCK_SEQPACKET is conneciton-oriented, while SOCK_DGRAM is not.

This will mostly matter on the server side of the connection (the process that listens on the UNIX socket) when there are multiple client processes talking to it:

With SOCK_DGRAM, you would get interleaved client datagrams directly on the listening socket. With SOCK_SEQPACKET, you would spawn a separate client socket for each client using accept, thus receiving datagrams from each client separately.

Quoting man 3 accept:

The accept() system call is used with connection-based socket types (SOCK_STREAM, SOCK_SEQPACKET).

Improve this answer

Comments

13

SOCK_SEQPACKET gives you the guarantees of SOCK_STREAM (i.e., preservation of ordering, guaranteed delivery, no duplication), but with delineated packet boundaries just like SOCK_DGRAM. So, basically it's a mix of the two protocol types.

In the TCP/IP-family, SCTP implements both SOCK_STREAM (TCP-like) and SOCK_SEQPACKET. Unfortunately it is not stock-available on Windows.

Improve this answer

Comments

7

socket(2) linux-provided manpage: “DGRAM: datagrams (connectionless, unreliable messages), SEQPACKET: sequenced, reliable, [two-way] connection-based data transmission path for datagrams". Significant difference.

unix(7) linux-provided manpage says: “SOCK_DGRAM, for a datagram-oriented socket that preserves message boundaries [but not necessarily order] [...] SOCK_SEQPACKET, for a connection-oriented socket that preserves message boundaries and delivers messages in the order that they were sent.”

The standard permits that you get reordered packets with SOCK_DGRAM. (In other words, if an OS hands them to you in order, that is an implementation-specific feature. Or just pure timing luck.)

There is flow control in the af_file/af_unix implementation in Linux, but that does not need to correlate with standard specified behavior at all.

Improve this answer

Comments

1

Like TCP and UDP sockets, there are SCTP(stream control transmission protocol) sockets which has two forms, (one to one) and (one to many) between endpoints. One to one uses SOCK_STREAM and one to many uses SOCK_SEQPACKET

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.