Forums Bug Reports New mIRC taking much longer on opening sockets

Was this done in 7.1 or 6.35?

The new version of mIRC asks Windows to return both IPv4 and IPv6 addresses for a domain name. It could be that for some users resolving IPv6 is slower than for other users for some reason. It is possible that the delay could be due to an ISPs name servers or your Windows configuration. I will change the DNS lookup in the next version so that it only asks for IPv6 if you have explicitly requested it by using/enabling features that need it.

7.1

Khaled: I'm on Windows 7, but I don't have any IPv6-capable interfaces other than loopback; the rest only gets IPv4. And I'd say it will still take some time until my ISP offers IPv6.
Making the request more explicit is IMO a good idea - just like the old one used to be and the new one has its switches for:
IPv4: /dns domain.tld or /dns -4 domain.tld
IPv6: /dns -6 domain.tld
both: /dns -46 domain.tld

My ideas about this problem:

Other apps can do IPv4/IPv6 resolution correctly, without such delays, and without the explicit need to enable IPv6. So it Can Be Done. This is the given, which we have to work with. So what's wrong? How do we fix it properly?

A likely cause of the problem is broken home NAT boxes which don't respond to AAAA queries at all, then mIRC times out after 15 seconds or so.

The recommended way to do DNS resolution is to use getaddrinfo(), the standard API lookup. I checked that this lookup, whereever i tried (both linux and windows), completely omits the AAAA lookup, if the PC has no IPv6 connectivity. This is done, explicitly, as a workaround for such broken NAT routers. If using getaddrinfo is impossible, then omit the AAAA lookup if IPv6 connectivity lacks. To know if you have IPv6 connectivity, look for the presence of global scope IPv6 addresses.

edit: i remember/read elsewhere that you do use getaddrinfo(), but you manually resolve v4 and v6 on their own. first, i advise against this, because the OS is designed to do this properly, taking care of all the edge cases, to make ipv6 work *without problems*. you're misusing the API. secondly, because you manually do v4 and v6 lookups independently, the above applies.

Thanks for the comments, however mIRC resolves IPv4 and IPv6 separately because testing showed that the API is broken and behaves differently under different versions of Windows. I think I may have mentioned that in a previous post. In any case, as I indicated in my above reply, this issue has been resolved for the next version.

resolved by explicitly requiring one to state that it's ipv6 with a -6 flag? do you intend this to be the long term solution?

in another thread you said you had difficulty with the idea of checking for ipv6 connectivity, saying you'd have to connect to some internet server for it. can you comment on the idea of looking for the presence of global scope ipv6 addresses? i can test things on XP and vista (and linux) if it helps.

This was resolved by making sure that mIRC only resolves IPv6 connections when necessary, eg. if mIRC is binding to an IPv6 address, or if IPv6 support has been enabled in the ports dialog, or if you are using the -6 switches, and so on. As far as I am aware, this covers all of the situations where IPv6 can be used. If I have missed one, or if it is not working for you, please let me know.