[Python-Dev] socket.SOL_REUSEADDR: different semantics between Windows vs Unix (or why test_asynchat is sometimes dying on Windows)

[Trent Nelson]

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