[Python-Dev] test_multiprocessing:test_listener_client flakiness

[Nick Coghlan]

Amaury Forgeot d'Arc wrote:
> 2008/6/18 Jesse Noller <jnoller at gmail.com>:
>> On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> Jesse Noller <jnoller <at> gmail.com> writes:
>>>> The server component *is* listening to localhost by default. The
>>>> client in the code I pasted has the server's .address attribute passed
>>>> into it to tell the client where to connect to.
>>> So I take it that the .address attribute is different from "localhost",
>>> but why? Is there any point in trying to be clever here?
>> No, it is *not* different than localhost - it *is* localhost as that
>> is the object.address of the server.
> 
> Well, on my win2k machine getfqdn('127.0.0.1') returns the actual name
> of the machine.
> This is the name that was stored in server.address.
> Hence my patch that simply remove the call to getfqdn.

Point of interest: I was involved in developing an application where we 
gave up on trying to persuade getfqdn() to return reliable results on 
Windows machines - regardless of which local network interface you use 
to do the lookup, Windows 2k3 is likely to return an answer of 
'computername.computerdomain' without bothering to consult the local DNS 
server (annoyingly, it used to do this right on previous Windows versions).

So I'm inclined to consider any code which expects a useful answer out 
of getfqdn() to be non-portable at best and outright broken at worst. We 
worked around the problem by only doing forward DNS lookups and always 
working with addresses in the IP domain.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org