Thank you for the clarification. I probably would have noticed that irc.link-net.net only underwent 4 retries (which would have made me investigate further into why), except I tend to instinctively reach for the abort button after I've already seen a few retries happen. (Too many servers like to punish people for rapid retries.
)
Anyway, the behavior still strikes me as being contrary to what a user would expect when all connection retry options are unchecked. Especially when you consider that the connections are technically succeeding -- the server is just throwing you out soon after. As a feature suggestion, then, perhaps beneath the existing "[ ] Enable connect retry" option, a "[ ] Enable retry on server reject" option could be added (checked by default in new mIRC installations so that people's existing scripts aren't broken by the behavior change it would otherwise cause).
As far as "retry #1" being shown repeatedly during DNS pool-based connection attempts, maybe a change in mIRC's wording would be appropriate to clarify the workings of this stuff. For example, assuming a hostname only has one IP, mIRC could say (as it now does):
* Connecting to irc.link-net.net (6667)
* Connect retry #1 to irc.link-net.net (6667)
* Connect retry #2 to irc.link-net.net (6667)
* Connect retry #3 to irc.link-net.net (6667)
etc., as usual.
But if a hostname had more than one IP, it could instead say:
* Connecting to irc.link-net.net (6667) (4 IPs in DNS pool, trying 67.43.232.178)
* Connecting to irc.link-net.net (6667) (4 IPs in DNS pool, trying 74.208.101.128)
* Connecting to irc.link-net.net (6667) (4 IPs in DNS pool, trying 76.73.15.38)
* Connecting to irc.link-net.net (6667) (4 IPs in DNS pool, trying 66.220.13.242)
P.S. I would've posted this in the Features Suggestions area, but don't want to litter the forum with two threads on the same thing. If there's a moderator watching, though, feel free to move it.
