Difference between UNIX domain STREAM and DATAGRAM sockets?

Question

This question is NOT for the difference between STREAM type and DATAGRAM type INTERNET sockets. I know that STREAM sockets use TCP, Datagram sockets use UDP and all the TCP,UDP stuff, packets arriving in order, ACK, NACK etc. I understand the importance of these over internet.

Q1) When I create a UNIX domain socket which is a local socket, how would it matter if the socket is STREAM socket or DATAGRAM socket. This type of socket would write the data to the socket file, would the protocol matter in this case since I am not transmitting data over a network? Is there any chance of data loss in this case if I use UNIX-based DATAGRAM sockets?

Q2) Does UNIX DATAGRAM sockets provide better performance than UNIX STREAM sockets?

Q3) How to decide for a STREAM/DATAGRAM UNIX based socket in my application?

Thanks

Solution 1

Just as the manual page says Unix sockets are always reliable. The difference between SOCK_STREAM and SOCK_DGRAM is in the semantics of consuming data out of the socket.

Stream socket allows for reading arbitrary number of bytes, but still preserving byte sequence. In other words, a sender might write 4K of data to the socket, and the receiver can consume that data byte by byte. The other way around is true too - sender can write several small messages to the socket that the receiver can consume in one read. Stream socket does not preserve message boundaries.

Datagram socket, on the other hand, does preserve these boundaries - one write by the sender always corresponds to one read by the receiver (even if receiver's buffer given to read(2) or recv(2) is smaller then that message).

So if your application protocol has small messages with known upper bound on message size you are better off with SOCK_DGRAM since that's easier to manage.

If your protocol calls for arbitrary long message payloads, or is just an unstructured stream (like raw audio or something), then pick SOCK_STREAM and do the required buffering.

Performance should be the same since both types just go through local in-kernel memory, just the buffer management is different.

Solution 2

The main difference is that one is connection based (STREAM) and the other is connection-less (DGRAM) - the difference between stream and packet oriented communication is usually much less important.

With SOCK_STREAM you still get all the connection handling, i.e. listen/accept and you can tell if a connection is closed by the other side.

Note that there is also a SEQPACKET socket type that's still connection oriented, but preserves message boundaries (which might save you from implementing a message-oriented layer on top of a STREAM socket).

I would expect data transfer performance to be similar for all of these types, the main difference is just what semantics you want.

Solution 3

1. One likely difference are message boundaries. Datagrams will be delivered as a whole with the datagrams being the natural message boundaries. With stream sockets you can read N bytes and the socket will block until N bytes are ready. But this means no obvious message boundaries.

2. All things being equal, if speed is a concern, instrument and measure. (I assume you already know that only a stream socket provides built-in reliable in-order transport, and only datagram sockets can be used to send to multiple receivers).

Comments

[Nikolai Fetissov]

Have you ever tried multiple receivers on datagram Unix socket?

[Jens]

No, and I wonder if there are systems where it would be possible... probably not, considering that AF_UNIX addresses are usually names in the file system hierarchy.

[Nikolai Fetissov]

Linux had some development for multicasting over Unix sockets, don't know if that ever made it into mainline kernel.

[cmeerw]

I would argue that the difference between connection-oriented and connection-less is much more important than the difference between stream and packet based communication.

[Nikolai Fetissov]

Yes, connection tracking is important too. Thanks.

[cmeerw]

Well, but that will still require some additional synchronisation mechanism and could make the implementation much more complicated (so it's usually only worth doing if lots of data needs to be transferred).

[Nikolai Fetissov]

I mean, if you send 18 bytes in one write() and expect to get 18 bytes in one read() the other side, that's a valid expectation for SOCK_DGRAM but not for SOCK_STREAM.

[JiaHao Xu]

The second one is probably wrong. Unix socket does not use IP stack at all, neither TCP nor UDP is used.