Amaury Forgeot d'Arc wrote:
2008/6/18 Jesse Noller <[EMAIL PROTECTED]>:
On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
