Author jnoller
Recipients jnoller, roudkerk
Date 2008-07-03.12:58:41
SpamBayes Score 0.000125133
Marked as misclassified No
Message-id <>
Per mail thread:

Attached is the patch to to drop the fqdn call.

Final suggestion from Trent:

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


> 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)).

How do I connect to an AF_INET Listener (i.e. SocketListener) instance 
whose 'address' attribute reports '' 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 ''.  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.
Date User Action Args
2008-07-03 12:58:45jnollersetspambayes_score: 0.000125133 -> 0.000125133
recipients: + jnoller, roudkerk
2008-07-03 12:58:44jnollersetspambayes_score: 0.000125133 -> 0.000125133
messageid: <>
2008-07-03 12:58:43jnollerlinkissue3270 messages
2008-07-03 12:58:42jnollercreate