RedAlert, you have absolutely no idea what you're talking about. "Since routers don't understand IRC or even TCP..." DUH. Anyone in the area of networking would be laughing at this nonsense (referring to the part of TCP, not IRC). This immediately invalidates anything you have to say in this subject matter.
Check your facts before you flame, please. Routers operate at the network layer (3) of the
OSI-model, TCP operates at the transport layer (4). Go read a networking-for-dummies book, or prove my ignorance by finding a router that generates TCP RST packets when it cannot find a route.
But for the original poster, the conclusion should still be the same, it's very unlikely for it to be mIRC's fault in any way.
I completely agree with that. However, this still does not contradict the fact that Raccoon's ICMP theory could be right.
As a side note, I did not use the term "half-open" (in references to sockets) in strict regard to it's technical definition of a state in which a socket has not yet received an ACK for it's SYN (and the term does exist, contrary to what you say).
I know that the term "half-open" exists (I've written my own SYN-scanner, have you?), I just said that the term, as you described it, does not exist. It doesn't. Please, don't just pick random technical terms and expect people to accept it, especially not when the term you picked already represents something different.
I was using it in reference to mIRC not being constantly aware of the state of the connection to the IRC server, because it's not constantly being validated;
Since you made such a mess of the explanation in your previous two posts, even contradicting yourself at this point (unawareness of normal connection termination VS. awareness of normal termination by means of FIN packets), I will leave it at saying that what you try to describe, are characteristics of TCP, not of IRC or mIRC, and since IRC uses TCP/IP, it also automatically and transparently deals with for example ICMP in exceptional situations. IRC doesn't use ICMP, but IP does.
Note that there is no such thing as "the state" of a connection, there are two sides which can both have different states - mIRC knows just as much as the underlying TCP stack, but it is of course simply impossible to know the state of the other side of the connection at every possible moment. All you can do is probe the validity of the connection once in a while - something IRC servers do, and mIRC doesn't.
I can be on IRC, completely unplug the power to my router for 30 seconds, have it retrain, then go on chatting on the IRC server as if nothing to my connection had happened (unless something requiring a validation, such as a ping, occurred within that time frame which could not be responded to); I've done this multiple times. This is contrary to a connection that is constantly validated such as when playing a game.
Nearly all games use UDP, which is connectionless, so there is no connection to be validated, just a lack of arriving packets - but that your game terminates so quickly has more to do with timeout values than anything else. I'm sorry, you probably already know all this, but the way you phrase your 'superior knowledge' makes it look like you only know half of the facts on this subject. A big mouth will really not get you the other half for free.
