Simple explanation of the Unix sockets

Question

I can search and I've already looked at the wikipedia entry and in some other places, but even though I have some programming experience, I don't really grasp the concept. Can you treat me like a 10 year old and give me a clear explanation on socket communication?

Answer 1

Let me give you an example: Say you want to communicate/chat with your friend, who lives not at your address. For that to happen, you have to establish a "communication channel". Say, you want to do this communication using telephones. You know that there is a network of telephone lines in the city that is extended to every house.

Now, there is a telephone socket in your house, and one in your friends house. For the communication to take place, you and your friend have to connect to the network by plugging your phone to the socket, at the both end of the communication. Sockets in programming is the same, conceptually, as the telephone sockets.

In programming, you have two processes (running programs) that want to communicate with each other. For that, they have to establish a communication link between themselves. Again, there is a network available, they just need to connect to this network using some sort of sockets. Unix sockets are one such socket that provides this connectivity/pluggability to the network. So, in each of the two programs, you will have some piece of code that does the job of connecting to the network through sockets.

The rest is details.

Answer 2

Unix sockets are a bidirectional socket - just like an IP based socket, which you are probably familiar with, and kind of similar to a pipe, which you are probably familiar with.

They have a small set of interesting properties:

• They are in the domain of "the local host" only - you can't access them over the network, only on the local machine.
• You can create them in "stream" mode, where they just pass data like a pipe as a stream of bytes.
• You can create them in "datagram" mode, where they retain boundaries between send operations. This allows you to retain framing without building your own framing protocol on top of a byte stream.
• They use the filesystem, or on Linux, an "abstract namespace", as their "address"
• You may be able to impersonate the other end, securely identify the connecting software, or pass file handles over the socket, depending on your OS.

Essentially, they are the equivalent of any other socket - they have slightly more interesting properties than pipes, but are not radically different otherwise. They do typically have higher IPC latency than a pipe does, and often larger buffers - though you may be able to tune that, and it depends on the platform.

The final interesting property to remember is that they use the filesystem as their namespace - so are like a named pipe, rather than an anonymous pipe, in that software with no previous relationship can communicate. (Abstract namespace sockets are the same, but the "file" path doesn't have to exist.)

There isn't anything deeper than that - they don't have any super-secret hidden property that makes them radically different from a typical pipe, or a TCP connection to localhost.

Answer 3

Programming Linux sockets, Part 1: Using TCP/IP worked quite well for me. It starts with an introduction to IP networks and network layers, then goes on by showing how to implement a simple echo server and client in both C and Python.