It is my understanding that sockets bound to ports using localhost will not be visible to the subnet because the binding is not with the nic IP address. Local processes connecting to such port will create a unix pipe instead of an IP socket. However if bound to the nic IP address the port is visible to the subnet. I want to learn the types of connections made when connecting to ports bound to localhost and the nic IP.

** Port bound to localhost **

  • local process connect using localhost creates a unix pipe
  • local process connect using nic IP creates a unix pipe
  • foreign process connect using nic IP cannot connect

** Port bound to nic IP **

  • local process connect using localhost creates a unix pipe
  • local process connect using nic IP creates an IP socket
  • foreign process connect using nic IP connects and creates an IP socket

Are the above statements correct? I am reviewing network programming from this site:


in hopes of more insight.

  • Some clarification is needed in your question! There are two types of sockets (well, let's simplify things): Unix Domain Sockets (what you incorrectly call "pipes") and Internet Domain Sockets. The first kind are strictly for IPC inside the same host. The second kind allows packets to flow across the Internet using IP. Both use the socket interface. And then you've got pipes, which are a different method of sending (via a "special" type of file) data between two processes (or more, chained together). Often this means connecting stdout from one process to stdin on another (and vv). Apr 16 at 17:35

2 Answers 2


Local processes connecting to such port will create a unix pipe instead of an IP socket.

Whether a process uses a pipe or a socket does not depend on the interface per se. It depends on which system services it calls.

To create a named pipe, the program calls mkfifo(2). To get a descriptor on that file, it calls open(2). ls -l shows a "p" in the status bits of a fifo. Anonymous pipes, created with pipe(2), have no name and are invisible to processes without a common ancestor.

To create a TCP socket, it calls socket(2) and then bind(2) to assign it a name for other processes to connect to. If the argument to bind is an external address, it will be visible to the network, else not.

You may be thinking of the loopback address If the program binds to that, it won't be visible or accessible from the network. Only processes running on the host machine can bind or connect to the loopback address.

It is also possible to create a TCP connection over something that looks a bit like a file, known as a UNIX-domain socket. In that case the argument to bind (and connect) has a filename. Because the name appears in the filesystem, it looks a little like a pipe, but ls -l shows an "s" among the status bits.

If you're interested in how all these strange distinctions came to be, NetBSD distributes two papers that date from their invention and are still relevant today. Look for An Advanced 4.4BSD Interprocess Communication Tutorial and An Introductory 4.4BSD Interprocess Communication Tutorial on the web.

  • I reviewed my 4.3BSD Unix OS "Imp Book" (1989). Binding on the loopback will keep traffic off the interface layer and allow local app socket connections. However binding on the machine IP allows subnet connections which (of course) pass through the interface layer/network layer/socket layer. I want to be confident that a local app connecting with a socket to another local app bound on the machine IP will deliver traffic as if bound on the loopback. The goal is to keep traffic off the interface layer.
    – sfanjoy
    Feb 7, 2014 at 17:55

I think those statements are correct. In fact, you could confirm it with a sniffer like tcpdump. If you could see traffic on "lo" interface, that means that the connection is using a unix pipe. On the other hand, if traffic is caught on "ethX", that means is using a network conection.

  • Not a Unix pipe per se, but rather a Unix Domain Socket, which is not the same thing! Apr 16 at 17:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .