+6
−0
+23
−0
Loading
The underlying net.Listener.Accept that SocksListener.AcceptSocks depends on may return different kinds of errors. AcceptSocks adds its own special errors on top. For some of these errors, we want to try the accept again, for instance if there was an EOF or timeout while reading the SOCKS request. For others, we want to stop accepting altogher, in particular when the underlying listener is closed. (It is very important to give up in that case, or else you enter a tight loop with Accept always failing immediately). The permanent errors we care about are of type net.OpError, which provides a Temporary method. http://golang.org/pkg/net/#Error With a type assertion, we can see if an error is of this type and whether it is temporary. Compare with this commit in net.http: https://code.google.com/p/go/source/detail?name=95448425041c and net.Error is mentioned in this blog post: http://blog.golang.org/error-handling-and-go I ran into this while trying to interact with a pluggable transport using socat. socat -v - SOCKS4A:127.0.0.1:X.X.X.X:YYYY,socksport=3128 socat sets the userid to your username ("david"), which tails to be parsed as a key=value string. This was causing the accept loop to terminate as if the listening socket had been closed.