[omniORB] Port allocation problem on windows (incl. patch)

Felix Nawothnig fn at drdannenberg.de
Wed Apr 14 20:28:02 BST 2010

> Windows has a fundamentally different understanding of the socket option
> SO_REUSEADDR than posix systems [...]

Ran into this too a couple of weeks ago.

> I didn't find out whether SO_REUSEADDR and SO_EXCLUSIVEADDRUSE (which is
> Microsofts' way of fixing the described issue) can be used together but
> using only SO_REUSEADDR on windows does more harm than good.

According to the pages I read on MSDN they can't.

>From what I've understood from MSDN the situation is like this
(Disclaimer: I have not tested all of this - this is mostly based on texts
spread through dozens of MSDN pages):

Micrsoft's SO_REUSEADDR implementation is purely insane and should never
be used under any circumstances (for obvious reasons).

To fix SO_REUSEADDR they invented SO_EXCLUSIVEADDRUSE which does nothing
but prevent _other_ applications from hijacking ports using SO_REUSEADDR -
but it does _not_ solve the original problem for which SO_REUSEADDR is a
solution on unix (the impossibility to rebind to sockets in TIME_WAIT

Also note that before Vista SO_EXCLUSIVEADDRUSE required administrative
rights, so it's not really usable when targeting XP or earlier systems.

So - as I understand this: If you want to safely listen to a TCP socket on
Windows you can not use SO_REUSEADDR, have to use SO_EXCLUSIVEADDRUSE, be
prepared that you might need administrative rights and live with the fact
that you have to wait for the TIME_WAIT to time-out.

I'd be curious if anyone can give me a hint on what the _fuck_ the
developers might have been smoking when they designed this.

Personally I simply use SO_REUSEADDR, create a named mutex to ensure my
application doesn't bind twice to the same port and add a disclaimer that
everything might break down horribly if someone runs another application
besides mine on that machine - Windows isn't really for multitasking you

As an alternative one could call netstat to see if there is another
application using that port right now. Race-con? What race-con?

Note that there is some text on
http://msdn.microsoft.com/en-us/library/ms740621%28VS.85%29.aspx talking
about SO_LINGER which _might_ be a solution to solve the TIME_WAIT
issue... maybe someone knows more about this.



P.S.: Sorry for this flamebait - I just wasted way too much time on this
issue until I finally gave up... I'd very much like to be proven wrong...

More information about the omniORB-list mailing list