I am writing some code using AF_UNIX sockets--AF_INET sockets is not an option. I'm trying to understand the differences between SOCK_STREAM and SOCK_DGRAM when using UNIX domain sockets--NOT AF_INET. My application will be using a simple protocol with defined headers so SOCK_DGRAM appears to the way to go to reduce reassembly of message on both sides of the connection. However I am not sure if there is something deep in the AF_UNIX implementation that will cause problems or sway my decision.

From the Linux Man pages it seems the reliability issues seen in INET SOCK_DGRAM sockets does not exist when using UNIX Domain (AF_UNIX) sockets. Therefore SOCK_STREAM and SOCK_DGRAM should be just as reliable. (referring to: http://linux.die.net/man/7/unix)

The only other difference I see is that AF_UNIX SOCK_DGRAM sockets support framing as they do for INET sockets. However I do not see anything that specifically states AF_UNIX SOCK_STREAM sockets are not framed based as well.

Does anyone know of other differences or other things to consider when selecting between AF_UNIX SOCK_DGRAM vs SOCK_STREAM?

Also does anyone know of a good reference for AF_UNIX sockets use? Information seems more limited with regards to AF_UNIX sockets.

Any help or suggestions are MUCH appreciated.

Hi,

Basically SOCK_DGRAM is used for UDP packets, SOCK_STREAM for TCP. As far as reliability issues, it's UDP vs. TCP issues - no guarantee for UDP, guaranteed delivery for TCP.

Ciao!

Personally until this post I have never heard about AF_UNIX sockets.
Correct me if I have misunderstood, but AF_UNIX is for one machine so the reliability issue is not a concern here( I have never known a datagram to not be sent on a local machine).

Stream communication works exactly like a pipe once connected. Datagram communication doesn't ever connect, so each individual write operation stands alone from all others. I'm not sure exactly how it works, but if you're sending structures then it might be the way to go. info libc is a decent reference, but I really think you need to just experiment with each to see how they work with what you're trying to do.
ta0kira

AF_INET supports datagrams over the Internet (i.e. UDP). AFUNIX is within the one machine, no external routing is done. I wonder if the AF_UNIX implementation could prioritize packets/messages differently for SOCK_DGRAM versus SOCK_STREAM but this is really part of my main question. Is there something different between the two socket types for UNIX Domain Sockets?

Hi -

Unix sockets are just another form of Interprocess Communication ("IPCs"); they're analogous to "named pipes" on Windows. The one place I ever really *needed* them was a somewhat esoteric problem where we used an AF_UNIX stream to pass an AF_INET socket descriptor from one process to another process.

Anyway - if it doesn't have to be 100% reliable, and if your datagrams don't absolutely need to arrive in a specific order, then use datagrams. Otherwise, you'd probably be wise to use streams.

'Hope that helps .. PSM

PS:
Here's a link with a bit more info:
http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html

I'd say streams are more appropriate for data that has an indefinite size, and therefore may or may not have to be broken up into parts. The network vs. local issue doesn't have much to do with it really, since the difference is only in addressing. A datagram is more of a "putting a discrete object into a box" operation where another process checks that box if it's expecting something. I use local sockets with stream communication often, and it requires format generation on the send end and format parsing on the receiving end in order to work (unless you're just sending files.) In other words, to send anything more complex than line-formatted text you'll probably need to design a custom protocol (I use something similar to XML.) Are you passing a stream of data, or the contents of a structure?
ta0kira

I am essentially going to send "structs" of data. These sockets will communicate internally between a number of different SW components. The ordering and reliability of the data is important.

According to the man pages I first referenced, the datagrams for UNIX domain sockets are as reliable as SOCK_STREAM and there is also no re-ordering issues. Therefore is there something else you are referring to? If so I assume this will also effect SOCK_STREAM for this implementation. Your comment is accurate for AF_INET sockets but I don't think it holds for AF_UNIX sockets.

Also, thanks for the reference, sadly it really says nothing about SOCK_DGRAM.

Yes, that is correct. The ordering and reliability issues only manifest themselves in the INET domain, as a side-effect of the connectionless nature of the datagram sockets.

In fact, there is a third kind of reliability about concurrent writes to the same UNIX-domain, datagram-socket destination, which is that writes (i.e., sendtos) are atomically added to the destination’s receive buffer (at least in linux). This is stronger than the same thing using FIFO’s in which atomicity is guaranteed only in PIPE_BUF chunks at a time.

Also, a difference in implementation in the UNIX domain vs. INET domain is that on many systems, you should bind sockets in the UNIX domain, whereas in the INET domain, if you don’t explicitly bind, a random, unused port will be assigned.

How does that happen? When you listen and accept without bind first?
ta0kira

So are writes using SOCK_STREAM also atomic?

I meant in using datagram sockets in the UNIX domain, you need to bind, but in using datagram sockets in the INET domain, you don’t necessarily need to bind. I was not talking about stream sockets (sorry if that was not clear).
Do you mean concurrent writes? Concurrent writes will obviously have two separate connections connections, so there can’t be any overlap (the point is moot).