You know, like "lions and tigers and bears, oh my"… okay, not funny, moving on…
The problem#
There's a lot of different ways to transmit streams of bytes between applications on the same host or different hosts with various reasons you might want to use each one. And sometimes the two endpoints might disagree on which one they want to be using.
The solution#
As it turns out, there actually is a single answer to
bridging any two byte streams: socat. The documentation
has plenty of examples. Here's a few I made up involving
named pipes and Unix sockets to go along with
my recent posts:
Bridge a pair of named pipes to a Unix socket#
socat UNIX-LISTEN:test.sock 'PIPE:pipe_in!!PIPE:pipe_out'
Builds a bridge such that a client sees a Unix socket test.sock and the
server communicates through two named pipes, pipe-in to send data over
the socket and pipe_out to read the data received over the socket.
Connect to Unix socket HTTP server via TCP#
socat TCP-LISTEN:8042,fork,bind=localhost \
UNIX-CONNECT:http.sock
For an HTTP server accepting connections via the Unix socket
http.sock, makes it also accept connections via the TCP socket
localhost:8042.
Forward a Unix socket over an SSH connection#
socat EXEC:"ssh remote 'socat UNIX-CLIENT:service.sock -'" \
UNIX-LISTEN:proxy-to-remote.sock
Note ssh can do the same without socat (including supporting
either side being a TCP port):
ssh -N -L ./proxy-to-remote.sock:./service.sock remote
But that demonstrates combining socat and ssh for getting access
to streams only accessible from a remote computer.