[Python-Dev] test_multiprocessing: test_listener_client flakiness

Amaury Forgeot d'Arc amauryfa at gmail.com
Wed Jun 18 18:48:20 CEST 2008


Hello,

2008/6/18 Jean-Paul Calderone <exarkun at divmod.com>:
> On Wed, 18 Jun 2008 18:35:26 +0200, Amaury Forgeot d'Arc
> <amauryfa at gmail.com> wrote:
>>
>> [snip]
>>
>> I just found the cause of the problem ten minutes ago:
>> It seems that when a socket listens on the address "127.0.0.1" or
>> "localhost", another process cannot connect to it using the machine's
>> name (even from the same machine).
>
> That's because when you try to connect to A:B you won't connect to a
> server listening on X:B - somewhat by design.  Changing the test to
> listen on A:B and X:B might fix it, but so would changing it to connect
> to the same address it listens to.
>
>> The best seems to listen with the empty address "".
>
> This will cause it to listen on all available interfaces, including
> public ones.  It's rather unlikely that someone from the internet
> will connect to the port while the test suite is running and use it
> to do terrible things to you, but it's not /impossible/.
>
> I'd suggest changing the client to connect to "127.0.0.1" or "localhost",
> instead.

OK, I am not a tcp expert.
How about the following patch?
It seems to me that it is wrong for the server to lie about the
address it listens to.

Index: ../../Lib/multiprocessing/connection.py
===================================================================
--- ../../Lib/multiprocessing/connection.py     (revision 64378)
+++ ../../Lib/multiprocessing/connection.py     (working copy)
@@ -216,8 +216,6 @@
         self._socket.bind(address)
         self._socket.listen(backlog)
         address = self._socket.getsockname()
-        if type(address) is tuple:
-            address = (socket.getfqdn(address[0]),) + address[1:]
         self._address = address
         self._family = family
         self._last_accepted = None



-- 
Amaury Forgeot d'Arc


More information about the Python-Dev mailing list