[Python-Dev] 2.4 asyncore headache

[Tim Peters]

[Nick Coghlan]
> Is test_socketserver currently passing for you?

Yes, on WinXP, and regardless of whether "currently" means before or
after Andrew reverted the change (& all the ZODB 3.3 tests pass under
current CVS Python on Windows after the reversion).

> A couple of days ago I ran the test suite with -unetwork, and that test
> failed, but I haven't got around to looking into it yet. Could this be
> related?

Which OS?  asyncore isn't involved in that test, so the patch could
not have affected it.  SocketServer.py has its own, separate code
using SO_REUSEADDR in some cases.

test_socketserver.pickport() never reuses a port number anyway. 
However, it may pick a port number that happens to be already in use
outside the test, so that could fail.  The port numbers it picks
depend on the process id, so a "picked a port # already in use"
failure mode may disappear on the next run.

> [rambling discussion of what I found out about this so far follows]
> 
> Anyway, after some hunting, the difference between Windows and Unix
> SO_REUSEADDR, is that on Unix, this only allows local address reuse when
> the existing socket is in a TIME_WAIT state. On Windows, it allows local
> address reuse _anytime_.
>
> See http://hea-www.harvard.edu/~fine/Tech/addrinuse.html. Look for the
> phrase 'security stigma', then read the bit starting with 'On some
> operating systems. . .'

It also says:

    This is only a problem on multi-user machines that don't have restricted
    logins, it is NOT a vulnerability from outside the machine. And it is easily
    avoided by binding your server to the machine's address.

If you're running a server on an open Windows machine, worrying about
details of socket reuse may not be the best use of your security time
<wink>.

> The issue is that if we *don't* set SO_REUSEADDR on Windows, then you
> get into problems with getting EADDRINUSE when you shutdown and restart
> a TCP/IP server on the same local address (generally if the socket has
> gone into TIME_WAIT while shutting down).

That's why ZEO calls asyncore's set_reuse_addr(), so that it can
shutdown/restart rapidly.  This has worked fine for years on Windows.

> Looking at MSDN, SO_EXCLUSIVEADDRUSE is a way to say 'make my socket
> behave like a UNIX socket without SO_REUSEADDR specified'. That is, with
> no options specified, a Windows socket is vulnerable to having another
> process come along, specify SO_REUSEADDR for their socket options, and
> succeed in reusing the same local port.
>
> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_so_exclusiveaddruse.asp)

asyncore shouldn't use this.

> What I can't find is a way to get Unix-like SO_REUSEADDR behaviour on
> Windows.

Well, the more I learn about this one, the less I care about it.  ZEO
can live with Unix-like SO_REUSEADDR behavior too -- I think.  I have
to wonder, because reports of "connection refused" kinds of ZEO test
failures have always been much more common on Linux boxes.