Creating a Proxy Server with Go

Creating a Proxy Server with Go(codingcookies.com)

51 points by jokeofweek 12 years ago | 18 comments

tptacek 12 years ago |

I know it's irrational, but it drives me a little nuts how the proxy idiom in go is "two goroutines implementing socket-to-socket copy". The inner handler loop of a proxy is a place where, to me, select/poll might actually make the code easier to follow; also, the idiom doubles the number of goroutines required to handle a given connection load, and while goroutines are cheap, they aren't free.

I know it's possible to pull select() into Golang programs (I ended up having to, to write a fast port scanner), but Golang people look at you weirdly when you tell them you did that.

pygy_ 12 years ago | |

Go is strongly opinionated and very normative (which is a good thing for its main target audience). It's not surprising it attracts people who would look down to you for departing from the norm, even if your choices are technically justified.

ithkuil 12 years ago | | |

Do you have any examples or data to support that there is any benefit by employing a explicit asynchronous IO pattern rather than relying on the Go IO libraries perform the select() (epoll or whatever...) syscall and then rely on the goroutine scheduler to switch control to who is registered to do something when the data is ready?

Is the default minimal stack segment size too big? Or the scheduler too heavyweight?

aaronblohowiak 12 years ago | |

errrm, why not just `func Copy(dst Writer, src Reader) (written int64, err error)` ? avoid having to select/poll and just let the io.Reader and io.Writer interfaces do the work for you... and if they implemenet WriteTo, all the better.

cmccabe 12 years ago | |

I've written a lot of code using select and poll, and I don't think it's ever come out "simpler and easier to follow" than code which just used blocking I/O.

tptacek 12 years ago | | |

We're not talking about the same thing. I'm not suggesting that Golang would be better off with fully evented I/O. In fact, the comment I wrote that you replied to agrees with what you just said.

mcot2 12 years ago |

I'm not sure I agree with how channels are used here. What's the point of this spaces chan? Why couldn't a simple atomic counter solve this (see sync/atomic)? Why allocate a thousand bools?

    // The booleans representing the free active connection spaces.
    spaces := make(chan bool, *maxConnections)
    // Initialize the spaces
    for i := 0; i < *maxConnections; i++ {
        spaces <- true
    }

}

Is this really how people use go???

axaxs 12 years ago | |

This is generally the Go way of limiting concurrency and usually the recommended approach. Some use empty structs in place of bools, but otherwise there doesn't seem to be a problem with the approach.

zemo 12 years ago | |

yes, using a channel's buffer for resource management like this is a common pattern. I can't say that I necessarily like this pattern, but... yes, it is common.

In this case, this particular part of the application is worth questioning, because the error condition isn't reasonable. Right now, if the proxy is full, it accepts a TCP connection from a client, and then it just ... stalls. It doesn't disconnect the client, it doesn't read from the client, it just hangs. So if a client were to actually connect to this proxy when it's full, they'd just open up a connection and wait.

Using sync/atomic package isn't common. Yes, you could do it, but it would be more common to just have a goroutine with a counter in it, and a select statement to serialize increment and decrement messages.

And then there are the actual handlers, which throw away the error information if there's an error actually writing to the connection.

mcot2 12 years ago | |

Looking at this some more... Why wouldn't you just make the waiting chan buffered and eliminate any tracking of connections.

jokeofweek 12 years ago | | |

Hey, poster here.

You're right that sync/atomic could've taken care of this, I wasn't aware of that package and figured channels were the way to go in Go.

As for making the waiting chan buffered, the reason I wanted to keep track of pending connections and active connections is because I'd like to proxy from a high-power server to a low-power server such as a Raspberry Pi. I agree with you that it could have done without though.

Thanks for the tips! :-)

nemothekid 12 years ago | |

I think in this case using atmoic.Add* is much clearer, and probably better.

lbarrow 12 years ago | |

sync/atomic would indeed be the way to solve this problem.

farslan 12 years ago |

The inbuilt reverseproxy is also handy for small tasks:

    package main

    import (
    	"net/http"
    	"net/http/httputil"
    	"net/url"
    )

    func main() {
    	target, _ := url.Parse("http://127.0.0.1:8000")
    	http.ListenAndServe(":80", httputil.NewSingleHostReverseProxy(target))
    }

This will http proxy :80 to :8000.

// The booleans representing the free active connection spaces. spaces := make(chan bool, *maxConnections) // Initialize the spaces for i := 0; i < *maxConnections; i++ { spaces <- true }

package main import ( "net/http" "net/http/httputil" "net/url" ) func main() { target, _ := url.Parse("http://127.0.0.1:8000") http.ListenAndServe(":80", httputil.NewSingleHostReverseProxy(target)) }