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

[Tim Peters]

[Sune B. Woeller]
...
> But then I stumbled upon this flag in the WinSock documentation:
> SO_EXCLUSIVEADDRUSE
> See the description here:
> <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_so_exclusiveaddruse.asp>

Right, I vaguely <wink> knew about that.  Note that the documentation
explicitly states that in the absence of SO_EXCLUSIVEADDRUSE,

    the port may be reused as soon as the socket on which bind was called
    (that is, the socket the connection was originated on or the listening
    socket) is closed.

IOW, that's your "case #b" from earlier email, and Windows is just
doing what's documented there.  Believe it or not, I haven't found any
Linux-ish docs as clear as these MS docs about the behavior of its
bind() in all cases.

There are problems with SO_EXCLUSIVEADDRUSE too, which Google will
find.  A big one is that many versions of Windows require admin privs
to set this option, including many versions of Windows Server, and
WinXP through SP1.  That was a bug, but it's only recently been fixed
(in SP2 for WinXP).

At this point, I wouldn't consider using it unless someone first took
the tedious time it needs to demonstrate that when it is used, the
thing that _I_ think is a bug here goes away in its presence:  the
seeming ability of Windows to sometimes permit more than one socket to
bind to the same address simultaneously (not serially -- Windows does
seem to prevent that reliably).

If you can, I would like you to try the ZODB 3.4 Windows socket dance
code, and see if it works for you in practice.  I know it's not
bulletproof, but it's portable across all flavors of Windows and is
much better-behaved in my tests so far than the Medusa Windows socket
dance.

> It is very interesting reading, especially:
> "An important caveat to using the SO_EXCLUSIVEADDRUSE option exists: If
> one or more connections originating from (or accepted on) a port bound
> with SO_EXCLUSIVEADDRUSE is active, all bind attempts to that port will
> fail."

Note too that they describe that as an "important caveat" (a warning),
not as "a feature".  They go on to explain that "active" means all of
the ESTABLISHED, FIN_WAIT, FIN_WAIT_2, and LAST_ACK states, meaning
the port stays tied up (in reality) for minutes even after the `r` and
`w` sockets are closed.  That's a 50% increase then in the # of ports
each trigger tiies up for an arbitrarily long time.

...

> There is a python bugfix for this, but only for python 2.4:
> http://sourceforge.net/tracker/index.php?func=detail&aid=982665&group_id=5470&atid=305470
>
> (It is added to version 1.294 of socketmodule.c)

That's not a real problem; if needed this could easily be done under
Python 2.3.5 too (the patch only adds a symbolic name for a fixed
integer; the integer could be hard-coded when not hasattr(socket,
"SO_EXCLUSIVEADDRUSE") -- much as the current Medusa dance hardcodes 1
instead of using socket.TCP_NODELAY).