Per mail thread:
http://mail.python.org/pipermail/python-dev/2008-June/080497.html

Attached is the patch to connection.py to drop the fqdn call.

Final suggestion from Trent:

> This is a common problem.  Binding to '127.0.0.1' will bind to *only*
> that address;

Indeed.

> binding to "" will bind to *all* addresses the machine
> is known by.

Agreed again.  I believe what we're dealing with here though is a lack 
of clarity regarding what role the 'address' attribute exposed by 
multiprocess.connection.Listener should play.  The way 
test_listener_client() is written, it effectively treats 'address' as an 
end-point that can be connected to directly (irrespective of the 
underlying family (i.e. AF_INET, AF_UNIX, AF_PIPE)).

I believe the problems we've run into stem from the fact that the API 
doesn't provide any guarantees as to what 'address' represents.  The 
test suite assumes it always reflects a connectable end-point, which I 
think is more than reasonable.  Unfortunately, nothing stops us from 
breaking this invariant by constructing the object as 
Listener(family='AF_INET', address=('0.0.0.0', 0)).

How do I connect to an AF_INET Listener (i.e. SocketListener) instance 
whose 'address' attribute reports '0.0.0.0' as the host?  I can't.

So, for now, I think we should enforce this invariant by raising an 
exception in Listener.__init__() if self._socket.getsockbyname()[0] 
returns '0.0.0.0'.  In effect, tightening up the API such that we can 
guarantee  Listener.address will always represent a connectable end-
point.  We can look at how to service 'listen on all available 
interfaces' semantics at a later date -- that adds far less value IMO 
than being able to depend on the said guarantee.

The connection patch was applied r64961

I made a mistake and reverted r64961 - self._address is used pretty 
heavily, and altering it the way outlined in the patch does not fix all 
instances.

Hello. I also experienced test_multiprocessing hang on win2k and I
workarounded this by this adhok patch.

Index: Lib/multiprocessing/connection.py
===================================================================
--- Lib/multiprocessing/connection.py	(revision 65551)
+++ Lib/multiprocessing/connection.py	(working copy)
@@ -217,7 +217,12 @@
         self._socket.listen(backlog)
         address = self._socket.getsockname()
         if type(address) is tuple:
-            address = (socket.getfqdn(address[0]),) + address[1:]
+            def getfqdn(s): # ???
+                if s == '127.0.0.1':
+                    return 'localhost'
+                else:
+                    return socket.getfqdn(s)
+            address = (getfqdn(address[0]),) + address[1:]
         self._address = address
         self._family = family
         self._last_accepted = None

I'm not familiar to socket, so probably this info is useless. ;-)

Jesse, thanks for capturing my e-mail thread in this issue.  Can you 
comment on my last three paragraphs?  Essentially, I think we should 
lock down the API and assert that Listener.address will always be 
a 'connectable' end-point.  (i.e. not a wildcard host, 0.0.0.0, that 
can't be bound to by a socket, for example)

This would mean raising an exception in Listener.__init__ if this 
invariant is violated.

> This would mean raising an exception in Listener.__init__ if this 
> invariant is violated.

If I understand the suggestion correctly, it would forbid people to
listen on 0.0.0.0. I'm not sure it is the right correction for the
problem. Listening on 0.0.0.0 can be handy when you are not sure which
address to use; it would be better to address the problem elsewhere.

IMO, the "FQDN removal patch" as uploaded by Jesse is simple and
straight-forward enough, provided it does fix the bug.

Unfortunately, the patch while simple, is too simple. The removal of the 
_address attribute breaks a lot more than it fixes (it's heavily used 
elsewhere)

Selon Jesse Noller <report@bugs.python.org>:
>
> Unfortunately, the patch while simple, is too simple. The removal of the
> _address attribute breaks a lot more than it fixes (it's heavily used
> elsewhere)

I don't understand what you mean. The patch you uploaded doesn't remove the
_address attribute.

See http://bugs.python.org/file10801/connection.patch

> I don't understand what you mean. The patch you uploaded doesn't remove the
> _address attribute.
>
> See http://bugs.python.org/file10801/connection.patch

Hmm. Then that was a mistake on my part: it's entirely possible the
patch didn't apply cleanly. I'll circle back to this shortly and
re-apply/test.

Trent/Antoine - I'm stuck on the fence about this. Per trent's own 
suggestion - removing the allowance for the 0.0.0.0 style address means 
that the self._address is always a connectable end-point: this provides 
clarity to the API.

However - to Antoine's point - using 0.0.0.0 to listen on "all 
addresses" is actually pretty common, especially when working with 
bigger servers (which generally have multiple cores). Using the 0.0.0.0 
address makes it easy to say "listen everywhere" - where, in the case of 
a Manager is actually very useful (you could have processes connecting 
to a Manager on a machine from different networks).

Attached is a cleaned up diff of the removal of the fqdn call - this 
should resolve the original problem while leaving the door open for the 
ability to connect to the 0.0.0.0 "address".

I need someone with a windows machine (Hi Trent!) that exposed the 
original problem to test the patch. Currently I'm favoring this rather 
than locking out the 0.0.0.0 option.

I confirmed this patch works on my win2000.
And I believe it works on Trent's machine, too.
http://mail.python.org/pipermail/python-dev/2008-June/080525.html

I've removed the fqdn call per the patch as of r65641

Lowering this to an enhancement to consider the removal of the 0.0.0.0 
functionality

I can confirm the patch works in Windows.  Regarding the 0.0.0.0 issue, 
perhaps we can compromise on something like this:

% svn diff connection.py
Index: connection.py
===================================================================
--- connection.py       (revision 65645)
+++ connection.py       (working copy)
@@ -217,6 +217,8 @@
         self._socket.bind(address)
         self._socket.listen(backlog)
         self._address = self._socket.getsockname()
+        if self._address[0] == '0.0.0.0':
+            self._address[0] = '127.0.0.1'
         self._family = family
         self._last_accepted = None


That way, we still support binding on all addresses, and self._address 
will always represent a connectable end-point.  Thoughts?

Le lundi 11 août 2008 à 19:58 +0000, Trent Nelson a écrit :
> +        if self._address[0] == '0.0.0.0':
> +            self._address[0] = '127.0.0.1'

Please no. If the user asks for 0.0.0.0, either obey or raise an
exception, but do not silently change the value.

My own humble opinion is that 0.0.0.0 should be allowed and, at worse,
the documentation may carry a warning about it.

I was thinking about this on the way home last night and concluded that 
my last suggestion (s/0.0.0.0/127.0.0.1/) is a terrible one as well.  
I'd be happy with a mention in the documentation (for now) stating that 
if you listen on '0.0.0.0', Listener._address won't be a connectable 
end-point (and you'll have to explicitly connect to 127.0.0.1, for 
example).

As for the original issue, Jesse I'm +1 on your connection_v2.patch.

documented in r70960