So yesterday I learnt ( Unix sockets )

[gilesgoat]

So .. to me "a socket" was "a virtual connection between a machine A and a machine B via UDP/TCP" "on some port" and with some IP addresses.

But yesterday I learnt ( and used ) there is an AF_UNIX type socket.

So what is actually that ? A sort of "named pipe" ? Does it really run TCP/IP on a named pipe ? Isn't it .. "a bit of an overkill" ?

[Dio]

As I understand it, it sets up a pipe for byte data with the various flow control primitives (select and the like). I don't think it's running TCP or UDP though - SOCK_STREAM and SOCK_DGRAM just map to different methods of sticking data into the intermediate buffer.

[KlaxonCow]

Does it really run TCP/IP on a named pipe ? Isn't it .. "a bit of an overkill" ?

Quite the opposite. It's a "shortcut" to avoid being overkill.

Think of it this way. If AF_UNIX didn't exist then, yes, you actually would be sending TCP / IP messages over the full network stack, but just targeting "127.0.0.1" (localhost) as the destination. It would go through the network stack and when it came time to send the message, as its destination is "localhost" then it just sends it back to its own input and then goes through the incoming network stack.

This would be overkill. Doing lots of pointless stuff, over a protocol that has stuff to deal with packet loss and unstable connections, which you don't need.

Here comes AF_UNIX. It gives the same programmatic socket interface, but it skips all that shit. It knows it's all on "localhost" and just cuts to the chase, without having to go through the network stack. The connection is always stable and there can be no packet loss, so it can skip over all that crap.

It's the "shortcut" that avoids all the "overkill". And the big advantage of this is that you can write one set of code, using sockets, and it works equally well locally or remotely.

You can write your client / server code and whether the server is local or on some remote machine, it just works. Same code.