If I understand you correctly, you're saying that mIRC will now do this:
1. Negotiate 3-way TCP setup handshake in full
2. Pause for a moment, to see if server initiates TCP teardown handshake (and if so, perform a sockread to get the ERROR message)
3. If no teardown witnessed within delay period, send login commands
If that is correct, then I do not believe it will solve the problem if:
1. Negotiate 3-way TCP setup handshake in full
2. Internet_lag >= your_delay postpones the arrival of server's PSK ACK "ERROR: throttled" packet + server's TCP teardown handshake packets
What apparently needs examination is why mIRC responds differently to Linux server teardowns vs. Windows server teardowns [when mIRC is simultaneously sending data to the server doing the teardown]. Right now, the bug doesn't occur at all if mIRC is dealing with a Linux server (regardless of the coincidental timing factors involved). If mIRC could be made to handle teardown handshakes from Windows servers as nicely as it handles teardown handshakes from Linux servers, the bug should "automatically" resolve, and possibly some other strange occurrences of [10053] would stop happening too.
