Fair enough. I thought mIRC had its own sockets library doing socket I/O of your own design. I was under that impression because other clients in my possession which themselves use winsock were not having the same problem under the same circumstances (as per my original screen capture at
http://img152.imageshack.us/img152/9743/toofast.png).
So ... if winsock does not expose programs to teardown handshakes, does this mean some of the [10053] errors people receive elsewhere are essentially unfixable -- and that they are unfixable because of Microsoft stupidity?
See, my impression was that the 10053 was happening in the login sequence as a result of mIRC sending
anything (not just login commands themselves -- but any commands) to a remote Windows server
after that remote Windows server began a teardown handshake (which, due to internet lag, really means mIRC innocently sends its data
before it sees the remote teardown packets locally arrive, but that the remote side
thinks mIRC sent that data afterwards). But since you now say this all depends entirely on winsock, the issue instead appears to become this: local winsock spews 10053 if remote teardown sequence changes midway from FIN/FIN ACK/FIN/FIN ACK to
Windows-style FIN/[...]/RST ACK sequence (but
not if remote teardown sequence changes midway from a FIN/FIN ACK/FIN/FIN ACK to
Linux-style FIN/[...]/RST sequence.)
If I am correct about that, then I'm wondering if the cause of other ambiguous [10053] errors is: a Windows server initiating a sudden TCP teardown sequence at exactly the same time as mIRC sends (a) a user /msg,
or (b) a script-initiated server command,
or (c) mIRC sends a PING (or replies to a server PING with a PONG),
or (d) (insert something else sent here).
This is only a curiosity. If it's true, I wouldn't be surprised that Microsoft made winsock incompatible with other winsocks in this scenario -- but what would be surprising is that they made it compatible with other linsocks in said scenario.
