[Updating issue with mailing list discussion; my reply to Jean-Paul]
> >"With TCP, we are never able to start multiple servers that bind
> > the same IP address and same port: a completely duplicate binding.
> > That is, we cannot start one server that binds 198.69.10.2 port 80
> > and start another that also binds 198.69.10.2 port 80, even if we
> > set the SO_REUSEADDR socket option for the second server."

> Notice that the quoted text explains that you cannot start multiple
> servers that etc.  Since you didn't call listen on either socket, it's
> arguable that you didn't start any servers, so there should be no
> surprise regarding the behavior.  Try adding listen calls at various
> places in the example and you'll see something different happen.

I agree in principle, Stevens says nothing about what happens if you 
*do* try and bind two sockets on two identical host/port addresses.  
Even so, test_support.bind_port() makes an assumption that bind() will 
raise EADDRINUSE if the port is not available, which, as has been 
demonstrated, won't be the case on Windows or Linux.

> FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote
> on Linux/BSD/UNIX/etc.  On Windows, however, that option actually 
means
> something quite different.  It means that the address should be stolen
> from any process which happens to be using it at the moment.

Probably explains why the python process wedges when this happens on 
Windows...

> There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think,
> which, AIUI, makes it impossible for another process to steal the port
> using SO_REUSEADDR.

Nod, if SO_EXCLUSIVEADDRUSE is used instead in the code I posted, 
Windows raises EADDRINUSE on the second bind().  I don't have access to 
any Linux boxes at the moment, so I can't test what sort of error is 
raised with the example I posted if listen() and accept() are called on 
the two sockets bound to identical addresses.  Can anyone else shed 
some light on this?  I'd be interested in knowing if the process wedges 
on Linux as badly as it does on Windows (to the point where it's not 
respecting ctrl-c or sigkill).


        Trent.