The fix has been released as part of Rebex FTP/SSL version 2016 R1.
thank you for your test app that we received via email. Using the test app we discovered it was actually a serious bug in Rebex components. Thanks for bringing this issue into our attention.
The bug is caused by an erroneous code in Socket4/Socket5 response reading code that is missing a check for closed connection and basically looks like this:
while (n < 8)
while (socket.Available == 0)
n += socket.Receive(reply, n, 8 - n);
Thread.Sleep prevents the loop from wasting CPU cycles before the timeout exception occurs, but when the socket is closed, the Receive method indicates this by returning zero, which triggers an infinite loop. And because the proxy connection code runs in a background thread, it keeps running even when the exception is thrown because the Receive method usage is wrong.
Surprisingly, this bug has been in our proxy code since the first release of Rebex FTP/SSL (called Rebex Secure FTP back then) in 2003, so it’s quite surprising it was only revealed now. This is mostly due to a fact that most Socks4/Socks5 proxies actually do return a response indicating a failure before closing the connection.
Interestingly, this code was left in our Socket4/Socket5 implementation by mistake. Calling Socket.Available is a very bad idea performance-wise and we removed all occurrences of it from our code a long time ago, but forgot to remove this one.
We will fix this and send you a link to a hotfix. Sorry for inconvenience!
This fix has been released as part of Rebex components 2016 R1.