Regarding the why, nwildner already wrote an excellent answer.
Here I will just focus on the how and the relative path usage.
Internally, while socket file can also be looked up by name (I guess), they are usually looked up by inode. In Linux, this lookup is ensured by the function unix_find_socket_byinode()
defined in net/unix/af_unix.c.
This can be easily checked as follow:
- Create two directories A/ and B/.
- Under each directory, make a process listen on socket files bearing the same name. With
socat
you would use a command such as:
$ socat UNIX-LISTEN:./my.sock -
- Now exchange the socket files by moving A/my.sock to B/ and vice-versa.
- From now on, if client application connects to A/my.sock it will contact the server B, and if it connects to B/my.sock it will contact the server A (note though that when the communication ends, the server process may legitimately delete what it thinks to be its own socket file).
I checked this behavior on a handful of Unix systems (Linux Debian, FreeBSD and OpenIndiana to get some diversity), so this behavior seems to be at least wide-spread, if not standard.
Absolute paths are usually used as a convention between the client and the server processes, as the client process may not otherwise know how to establish the initial communication with the server.
However, if this initial communication is not an issue, it seems therefore safe to use relative paths for socket files creation, allowing to avoid path length issues when the socket file location is not directly controlled by the server process.