Key point:  no socket is _listening_ on address ("", 19999)
after this close().  From what comes later, I guess you believe that
no socket should be allowed to listen on that address again until all
connections made with that `a` also close, but I don't think you'll
find anything in socket documentation to support that belief.  In the
world of socket connections, what needs to be unique is _the
connection_, and that's a 4-tuple:

    (side 1 host, side 1 port, side 2 host, side 2 port)

There's no prohibition against seeing either side's address in any
number of connections simultaneously, you just can't have two
connections simultaneouly that match in all 4 positions.  It so
happens that Windows is happy to allow another socket to bind to a
port the instant after a socket that had been listening on it closes
(and regardless of whether connections made via the latter are still
open), but I don't believe that's a bug.

Hi Tim,
You are right, I had things confused quite a bit there. Well, I guess I learned
quite a bit about sockets in the last few days :)

What I appear to be seeing is that sometimes-- rarely --Windows allows
binding to a port by two sockets simultaneously, not serially as
you're showing here.  Simultaneous binding (in the absence of
SO_REUSEADDR on Windows) is a bug.

So -i keeps the connection open -- these programs never "finish".

By design, to keep the sockets around, and being able to inspect them 

Then lets try to setup a second
client/server pair, on the same port (19999). The expected outcome of
this is that the bind() call in sock_server_reader.py should fail with
socket.error: (10048, 'Address already in use').

Sorry, I don't expect that.  sock_server_reader is no longer listening
on port 19999, so there's no reason some other socket can't start
listening on it.

point taken.


I showed an example before of how you can get any number (well, up to
64K) of sockets simultaneously alive saying they're bound to the same
address, on Windows or Linux.  The socket returned by a.accept()
always duplicates a's (hosthame, port) address.  That's so that if the
peer asks for its peer, it gets back the address it originally
connected to.  It may be confusing, but that's how it works.

yes, I was aware of that ;) (I thought it was an error for another _server_ socket to start listening on the same port, even when the first server socket is closed, as long as there were client sockets connected via the port. But I agree it is not.)

Windows and Linux seem to differ in how willing they are to reuse a
port after a listening socket is closed, but dollars to doughnuts says
Microsoft wouldn't accept a claim that their behavior is "a bug".

4) python -i sock_client_writer.py
Now one out of two things happen:

a) The client prints:
   w connecting:
   Traceback (most recent call last):
     File "c:\pyscripts\sock_client_writer.py", line 7, in ?
       w.connect(('', 19999))
     File "<string>", line 1, in connect
   socket.error: (10061, 'Connection refused')

How often do you see this?  I haven't seen it yet, but I can't make
hours today to do this hand.

The problem with a failing connect, and as consequence a hanging accept:
I have tested with your socktest111(), and experience the same thing with that as with my own one-go scripts: The socktest111() test hangs on accept() after a few (1, 2, 3...) cycles, because the w.connect fails (10061, 'Connection refused').

Well, enough with that - I can only recreate that problem on my own machine.

I have run the same test on another win xp home, and win 2K without that 

(I have tested with your newest script also, see the next mail).


Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to