[Python-Dev] test_multiprocessing:test_listener_client flakiness
Nick Coghlan
ncoghlan at gmail.com
Thu Jun 19 01:03:08 CEST 2008
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
More information about the Python-Dev
mailing list