socat TCP file server

Question

I'm trying to set up a simple socat fileserver using TCP to send small files (~100KB).

Here are the one-line servers and client for one file:

Server: socat -u -d -d OPEN:file.dat TCP-LISTEN:<port>,reuseaddr,fork

Client: socat -u -d -d TCP:<server>:<port> OPEN:file.dat,creat

The first data transfer always works, but the following are not always working. Most of the following transfer create an empty file on the client-side. The problem persists with multiple clients transfering once, and I veryfied that data is not transfered when the bug occurs, but the log and return values doesn't indicate any errors, just a shorter data loop.

I tried pretty much every option mentionned here: http://www.dest-unreach.org/socat/doc/socat.html

The only way I found to make it work multiple consecutive times is to remove the fork option from the server listenner and to wrap the whole commande line in a bash loop, but of course it fails for multiple clients.

I tried with Ubuntu, Fedora, Redhat and FreeBSD.

Am I missing something or is this a bug ?

Answer 1

I had the same problem and it took me hours to figure out what I was doing wrong. I still kind of don't but I know at least how to make it work. I was using:

socat -u FILE:/tmp/test.txt TCP-LISTEN:5778,reuseaddr,fork

And it worked as expected when I switched to:

socat TCP-LISTEN:5778,reuseaddr,fork FILE:/tmp/test.txt

I'm not sure what's actually changing but dropping the -u flag and swapping the order of the addresses will open up the socket for multiple client calls. I stumbled across it while trying to duplicate a known working example of a server.

Also my client was simply socat -u TCP:localhost:5778 STDOUT. It works without the -u as well.

Answer 2

man man

$ man socat | grep -m1 '\-u' -A3
       -u     Uses  unidirectional  mode.  The  first address is only used for
              reading, and the second address is only used for writing  (exam-
              ple).

even just help

$ socat  -h | grep -m1 '\-u '

...

Answer 3

This is because on the server there is a single file source, and multiple file sinks (TCP connections, forked). The first client consumes all the file, leaving the file position at EOF (end of file). Any subsequent TCP clients find themselves with nothing to read as they are all using the same file source.

This is more of a design aspect of socat than a bug. I do not know of a way for new connections to reset the seek position on the source file.