Why is "fork" needed by socat when connecting to a web server?

Question

I am trying to understand tcp connections between a browser and a web server. I have a web server running on my local machine, and can browse to it just fine, as expected, using localhost:3000 or 127.0.0.1:3000. (I am running "rails s"and WEBrick.)

I wanted to put a software intermediary between the browser and the web server, and so began experimenting with socat. The following works just fine:

socat TCP-LISTEN:8080,fork TCP:localhost:3000

I can browse to localhost:8080 and things work as expected. However, if I omit the ",fork" argument like so,

socat TCP-LISTEN:8080 TCP:localhost:3000

the local rails web site is quite broken looking in the browser.

Why is that fork argument necessary? Why wouldn't a browser <--> web server connection work without it?

Answer 1

Without the fork, socat will accept a single TCP connection, forward data bidirectionally between the two endpoints for as long as that connection remains open, then exit. You can see this yourself easily:

• Run socat in one terminal window
• Telnet to localhost 8080 in another terminal window. It connects to the socat instance.
• Telnet to localhost 8080 in a third terminal window. You get a connection refused error, because socat is not listening for new connections anymore: it has moved on to servicing the one it already got.
• Type an HTTP request into the second terminal window. You'll get an HTTP response, and then socat will exit as the connection is closed.

The fork option just makes it fork a new child to process the newly accepted connection while the parent goes back to waiting for new connections.

socat's use of fork() rather than something more sophisticated like preforking or connection pooling is the reason you wouldn't want to implement high-performance middleware with socat!