UNIX domain sockets and FIFO may share some part of their implementation but they are conceptually very different. FIFO functions at a very low level. One process writes bytes into the pipe and another one reads from it. A UNIX domain socket has the same behaviour as a TCP/IP socket.
A socket is bidirectional and can be used by a lot of processes simultaneously. A process can accept many connections on the same socket and attend several clients simultaneously. The kernel delivers a new file descriptor each time connect(2) or accept(2) is called on the socket. The packets will always go to the right process.
On a FIFO, this would be impossible. For bidirectional comunication, you need two FIFOs, and you need a pair of FIFOs for each of your clients. There is no way of writing or reading in a selective way, because they are a much more primitive way to communicate.
Anonymous pipes and FIFOs are very similar. The difference is that anonymous pipes don't exist as files on the filesystem so no process can open(2) it. They are used by processes that share them by another method. If a process opens a FIFOs and then performs, for example, a fork(2), its child will inherit its file descriptors and, among them, the pipe.
The UNIX domain sockets, anonymous pipes and FIFOs are similar in the fact they use shared memory segments. The details of implementation may vary from one system to another but the idea is always the same: attach the same portion of memory in two distinct processes memory mapping to have them sharing data
(edit: that would one obvious way to implement it but that is not how it is actually done in Linux, which simply uses the kernel memory for the buffers, see answer by @tjb63 below).
The kernel then handles the system calls and abstracts the mechanism.
sockets are a kernel API for communication. Using the socket API, you can exchange data between two endpoints over TCP/IP connections, SCTP associations, UDP datagrams, or between two processes (datagram or connection) using Unix domain sockets...
Being a kernel API, any interaction with a socket is via system calls (socket, bind, connect, listen, accept, sendmsg, send, recv, write/read...).
So typically, strace will be able to trace those because strace traces system calls. The only communication mechanism that strace can't trace is IPC over shared memory (because reading/writing something in memory obviously doesn't involve a system call).
More likely, in your case, it's something else. My bet would be that the application is multi-threaded and you're not stracing the right thread. Or it could be that the application is setuid/setgid and not started as superuser.
If you want to strace what's being exchanged over Unix domain sockets, the options are:
strace and other ptrace debugger (trace the server or the clients)- The audit system (
auditd/auditctl), again that traces the system calls
- use a
LD_PRELOAD trick to wrap the system calls that interact with the socket
- instrument the code of the application to add logging there.
- systemtap and other low level kernel tracing/debugging systems as already mentioned
- insert a man in the middle.
For the MITM, you could for instance use socat. Here for a connection oriented Unix domain socket like for X11:
socat -x unix-listen:/tmp/.X11-unix/X42,fork unix:/tmp/.X11-unix/X0
DISPLAY=:42 xlogo
Then, you see the X11 traffic that xlogo and the X server exchange.
Best Answer
No, there are no spare sockets just floating around, But they are easy to make, so easy that you may have done so if the directory you were creating them in existed and you had write permission. To make your example work you probably need
mkdir /some; chown vlc_user.rmt_grp /some; chmod 0775 /some. and it is easier if the remote control and the player run as the same user.