[Python-Dev] 2.4 asyncore headache
ncoghlan at iinet.net.au
Sat Aug 14 01:30:47 CEST 2004
Tim Peters wrote:
>>>Now somebody, for some reason, added this to 2.4's asyncore.py:
>>> if sys.platform == 'win32':
>>> reuse_constant = socket.SO_EXCLUSIVEADDRUSE
>>I'll back out this change.
> But only if that's the right thing to do <0.9 wink>. I gave up
> reading the Windows SO_EXCLUSIVEADDRUSE docs after it got to the "This
> situation can be quite complicated; even though the socket has been
> closed, the underlying transport may not terminate its connection ..."
> part. But by that point, it sure didn't seem like SO_EXCLUSIVEADDRUSE
> was a plausible Windowsy way to spell the Unixy SO_REUSEADDR ...
Is test_socketserver currently passing for you?
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
[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. . .'
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).
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.
What I can't find is a way to get Unix-like SO_REUSEADDR behaviour on
Nick Coghlan | Eugene, Oregon
Email: ncoghlan at email.com | USA
More information about the Python-Dev