[Zope] Re: Running more than one instance on windows often block each other

[Sune B. Woeller]

[...]
> 
> Key point:  no socket is _listening_ on address ("127.0.0.1", 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 afterwards.


[...]
>>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(('127.0.0.1', 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 problem.

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


/sune