You are correct! I looked up the definition of REUSEADDR...

from TCP/IP Illustrated V2, Wright & Stevens:

        Allows the process to bind a port number that is already in
        use, but the IP address being bound (including the wildcard)
        must not already be bound to the same port.

SO_REUSEPORT allows the reuse of both the IP address and the
port to be reused. REUSEPORT is only useful for IP multicast since the
behaviour is undefined when using TCP since two sockets with the
same port and IP address can not be bound.

I did not find any reference to the TIME_WAIT state issue. The only
case that Wright and Stevens alluded to was when two sockets were
connected to the same port but on two different IP addresses. As in
the case of telnet where one socket is attached to (192.163.1.25, 23)
and another socket is attached to (127.0.0.1, 23). This is allowed
only if SO_REUSEADDR is set.

The short answer: it is a M$ bug (what a suprise) since it allows TCP
to get into an illegal state with two protocol control blocks pointing
to identical IP address/port combinations. I doubt that this actually
works in windows. Something to check in my spare time... 

So, I guess the correct solution would be to #if NT around the
setsockopt for us unfortunate M$ users.

Thanks,
Will

ts <decoux / moulon.inra.fr> writes:

> >>>>> "W" == William Sobel <wsobel / Barra.COM> writes:
> 
> W> The problem you are experiencing seems to be intentional. The socket
> W> is set to enable reuse of the address. I think that UNIX ignores this
> W> for all but UDP multicast sockets, Windows appears to honor the
> W> request, for what reason I can not guess. (Is this a Windows bug or a
> W> Ruby bug?) Any idea why this option was set?
> 
>  Windows fatally :-)
> 
>  Seriously, SO_REUSEADDR allows your server to bind to an address which is
>  in a TIME_WAIT state.  It does not allow more than one server to bind to
>  the same address.  
> 
> Guy Decoux