The socket of the actual connect to the SOCKS server does not have to be in non-blocking mode just because the socket original connect was. Retaining the non-blocking mode of new connections seems to cause problems with some applications using the transparent SOCKS library.
Unfortunately, toggling non-blocking places the application at the mercy of the SOCKS server which might itself be slower than expected cause everything to be sluggish. Whatever is causing the problem with certain applications seems to be a bug in the way they handle connections, not the library. Nevertheless, there may be a way to handle it through the library by acting upon the first call to close a connection associated with an incomplete SOCKS request state.
Here is a patch that restores some of the functionality removed in the version transition from TSOCKS 1.8 beta 2 to TSOCKS 1.8 beta 3 in multi-compatible, soft-coded way.
Log in to post a comment.