3

Am I right that

  • When two processes communicate by network sockets, each process create a socket (each socket belongs to one process), and the processes communicate by their sockets.

  • When two processes communicate by Unix domain sockets, only one socket is created (which doesn't belong to any process), and both processes connect to the same socket?

7

You're confusing two things here.

A socket is a file descriptor - a handle - given to a program so that it can use a network connection in almost the same way it uses files. The socket API is protocol-independent; sockets can be created for IPv4 connections or IPv6 ones, but (given kernel support) also for things like DECnet, AppleTalk, or read Ethernet.

Since the socket API is fairly easy to use but since talking to a process on the same machine using an actual network protocol is rather inefficient, at some point the UNIX domain socket was created to allow use of the socket API without that inefficiency. It also adds some extra features; e.g., it is possible to pass file descriptors to another process over a UNIX domain socket.

When one uses UNIX domain sockets, both processes still hold a socket, one for each side of the connection. The use of the socket is no different from, say, IPv4 sockets, apart from the initial connection setup.

One thing the socket API cannot do without is an address; it is not possible to create a socket without passing it an address to talk to, and this is no different for the UNIX domain socket. Since it's UNIX, where everything is a file anyway, it was decided to make these addresses look like filenames. And since we're already doing that, it makes sense to make these addresses appear in the file system, since that makes it easy to spot them.

Unfortunately, the name given to these things in the file system was also 'UNIX domain socket' (or at least, that's what people started calling them). They're not the actual sockets in the sense of the socket API, however; they couldn't be, since those are just a number. As such, their counterpart in an IPv4 socket is not that number, but instead the IP address and port number of the peer you're talking to.

Occasionally, I'll add that since the socket API doesn't deal with files directly, these filesystem representations aren't strictly necessary. Indeed, Linux has a concept of 'anonymous UNIX domain sockets', which are just that: UNIX domain sockets without any link in the filesystem...

  • Thanks. I have an example. In SSH local port forwarding specifying a local port, destination host and destination port, when a process running on the local host attaches to the local port, are there a Unix domain socket created for the process and a Unix domain socket created for the SSH client? Is the local port part of both sockets? (See unix.stackexchange.com/q/236864/674) – Tim Oct 18 '15 at 18:45
  • No. You should think of UNIX domain sockets as a different network protocol. The SSH port forwarding just uses TCP ports to localhost; anything else would require it to translate the network protocols, which would not be efficient. – Wouter Verhelst Oct 18 '15 at 19:19
  • Thanks. when a local process attaches to the local TCP port specified in SSH local port forwarding, does the process communicate with the SSH client using network sockets? If yes, does the local TCP port belongs to both network sockets used by process and by the SSH client? – Tim Oct 18 '15 at 19:25
  • Hello, could you give some examples for "When one uses UNIX domain sockets, both processes still hold a socket, one for each side of the connection"? – Tim Oct 20 '15 at 19:31
  • @WouterVerhelst, You might want to touch upon named pipes too... – Pacerier Feb 19 '17 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.