Tags: rofl0r/microsocks
Tags
improve throughput in copyloop() using bigger buffer - refactored clientthread to put the handshake code into its own function, since it used its own 1K stack buffer. by returning from the function before calling copyloop, we have that space available in the new stackframe. - since getaddrinfo() was the main stack consumer in the entire code, we can safely use at least half the available thread stack size for the copyloop to achieve higher throughput. in my testing with pyhttpd it turned out that 64k is the sweet spot to have minimal syscall overhead, but 16k is very close, and it allows us to keep the minimal memory usage profile. this is in response to #58 (comment) which links to a repo that tests different socks5 servers performance on gigabit links. also closes #10
Remove nugatory EC_TTL_EXPIRED error before idle connection closes. In the case where connect_socks_target() succeeds, the proxy client receives an EC_SUCCESS message and the client thread passes control to copyloop(), which then proxies application-layer data. If both the client and remote connections are idle for too long, the call to poll() inside copyloop() returns zero, giving microsocks the opportunity to reap the inactive connection. Before closing the idle connection an EC_TTL_EXPIRED message is returned to the client. Since the client has already previously received EC_SUCCESS, it believes it is receiving application-layer data from the proxied target. This causes the user to receive a false \x05\x06\x00\x01\x00\x00\x00\x00\x00\x00 data sequence before the connection is closed. This commit removes the call to send_error() that returns the EC_TTL_EXPIRED message for an idle connection. An EC_TTL_EXPIRED error can still correctly be returned in the case where the initial socket() call to the remote address returns ETIMEDOUT. Fixes issue #53.
fix rfc1929 user/pass auth subnegotation response version field the version field is repurposed here to mean "version of the subnegotation", which in this case is 1, not 5, as intuitively expected. interestingly, most socks5 clients don't check the version respond, rather only the success field.