On Jan 6, 2014, at 3:47 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 06/01/14 08:26, Maciej Wasilak wrote:
Hello,
I've tried to use Twisted names.client.getHostByName() method to resolve some addresses for my UDP based app. By default getHostByName() always returns IPv6 address. I don't always have end-to-end IPv6 connectivity,
I'm not sure if t.n.client implements the same stuff that getaddrinfo does, namely RFC 6724 address selection rules and behaviour, and in particular if it has an equivalent of the AI_ADDRCONFIG flag.
After Twisted 13.2 announcement I've checked the new HostnameEndpoint implementation to find possible solution (it seems to be dedicated to solve similar problems, but for TCP-based protocols). However it seems to use deferToThread(), and built-in Python getaddrinfo().
My questions: 1. Is using deferToThread() a preferred solution?
IMO *all* applications should *always* use getaddrinfo() for resolution of user-supplied names. It really really annoys me when people decide to re-invent it - this is hard to get right, and apps like Chrome having their own implementation precludes things like DHCP-based 6724 tables in the future.
So yes, use "deferToThread" and "getaddrinfo". Note that you should not, in general, specify the address family; let the AI_ADDRCONFIG flag sort that out for you.
I have a minor quibble - all applications deployed to other people’s hardware ought to always use getaddrinfo, because the essence of GAI is that it respects local configuration of the platform. No matter how “hard” you try to get it “right”, you can’t ever know what the platform is doing with hostname resolution because it simply isn’t exposed any other way, let alone any asynchronous way.[1] However, if you’re building a big service to run in the cloud, or on a VPN, on specially-tuned machines that you configured, using twisted.names can be more scalable and allow you to react more reasonably to high load situations. Or, at least, it will give you a level of control so that you can tune it, since just doing potentially blocking platform stuff in a thread is not amenable to tuning. -glyph [1]: Actually it is sometimes exposed, for example with platform-specific APIs like <https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFHostRef/Reference/reference.html> and <http://msdn.microsoft.com/en-us/library/windows/desktop/ms741522(v=vs.85).aspx>. But you know, not on, like, Linux.