On Feb  5 12:26, Corinna Vinschen wrote:
> On Feb  5 02:29, Mark Geisert wrote:
> > Using Cygwin's bindresvport() is the best solution because Cygwin keeps
> > track of the last port number it has allocated *to any Cygwin program*.
> > This is the only approach that can deal with multiple programs and multiple
> > calls in one program.  So we need to nail down why it doesn't seem to work
> > for you.
> 
> Apart from all the above, there may still be a problem in the given scenario.
> 
> To reiterate the problem we observe:
> 
> - socket()
> - setsockopt (SO_REUSEADDR)
> - bind() succeeds
> - connect() fails with EADDRINUSE while socket is still in TIME_WAIT
> 
> using bindresvport in place of bind only marginally changes the
> situation, in particular if the second parameter is set and requests a
> port number != 0.  What happens in that case is that bindresvport calls
> bind with this port number and checks if bind returns EADDRINUSE.
> 
> Only then it tries to bind other port numbers in the reserved range.
> But we now know that bind will never return EADDINUSE if the SO_REUSEADDR
> socket option has been set.
> 
> Even assuming the process calls bindresvport(sock, NULL) we may end up
> returning a port number already in use if the process is the only Cygwin
> process on the system.  The reason is that Cygwin uses a round robin
> approach which relies on having a globally shared value called
> last_used_bindresvport.  If the process is the only Cygwin process on
> the system, this information is lost after exiting the process, so the
> next process will start with the same start port number and bind will
> again fail to notice the client with EADDRINUSE.
> 
> What potential solutions to this problem do we have?
> 
> - bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
>   sure bind fails.

Nope, no way.  Even enforcing SO_EXCLUSIVEADDRUSE results in the
second bind succeeding and the subsequent connect failing.  The
entire SO_REUSEADDR/SO_EXCLUSIVEADDRUSE semantics only works as
desired on the server side apparently

> - bindresvport could check every local address for being free prior
>   to calling bind.  However, there's a potential race here.
> 
> - DisconnectEx?  Never tried this Winsock extension but it might be
>   worth a shot.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat