RPC clnt_create() adress already in use

[Corinna Vinschen]

On Feb  5 02:29, Mark Geisert wrote:
> PAULUS, Raimund, TI-ABN wrote:
> > Hello Mark,
> > 
> > unfortunately i must correct my statement from Friday.
> > The program works, but only if the connections to the server are established in a loop inside the program.
> > If the program ends and you start it anew, a connection is not possible for a long time. you have to wait before you can establish a new connection.
> 
> That isn't what I saw in my testing.  At one point I had three copies of
> your test_rpc.exe running simultaneously and they all were able to establish
> 20 connections and the allocated port numbers were interleaved.
> 
> Are you running your test programs directly from a Windows Command Prompt or
> from one of the Cygwin shells like bash?
> 
> > Actually only our approaches in the original bindresvport() seem to work for all cases.
> > You have proposed to use the static variable usecount in bindresvport(). But how is the value of the variable handled if the program starts anew. Is it possible to get an used portnumber
> > and run in EADDRINUSE?
> 
> You must understand that none of the libtirpc approaches is guaranteed to
> work 100% of the time.  The problem is that without a lot of extra work we
> can't get libtirpc to "know" which ports to avoid.  Our approaches are just
> different strategies for avoiding a port collision, with different chances
> of working.
> 
> Libtirpc's original approach is essentially to have a range of port numbers
> it will try, 600 thru 1023, start with one of them randomly (based on the
> pid of the calling process), increment by one on each use.  This won't work
> when you're calling bindresvport() multiple times within one program because
> it starts from the same port number each time.
> 
> My "usecount" modification changes things so we start with the same port
> number as before but increment each time we bindresvport().  Good for one
> program making multiple calls and sort of good for multiple programs at same
> time.. but there is a chance of port number collision between the programs.
> 
> 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.

- 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20180205/4cdaef6d/attachment.sig>