> 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.
Thoughts?
Trent.
_______________________________________________
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
