On 08/01/14 23:05, Glyph Lefkowitz wrote:
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 g
On Jan 6, 2014, at 3:47 AM, Phil Mayers 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 ha
Hello,
6 sty 2014 12:50 "Phil Mayers" napisał(a):
> 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 precl
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 imp
On Jan 6, 2014, at 12:26 AM, Maciej Wasilak wrote:
> 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(),
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, so
it often causes communication to fail. I've found a solution to override
