Web lists-archives.com

Re: RPC clnt_create() adress already in use




Hi Mark and Corinna,

i use my program in a production environment running 24 hours a day. Therefore it must be as stable as possible and I have different test scenarios. Normally the program is the only Cygwin program running at this time. It is running only for a short time for data exchange with a linux server. Subsequently an other program (not Cygwin) does the rest of the job with the transferred data. After some seconds (or minutes) the other program starts my program again for data exchange. My program is started by a VB-script (windows script host) or a DOS shell script but never in the bash.

Raimund


-----Ursprüngliche Nachricht-----
Von: cygwin-owner@xxxxxxxxxx [mailto:cygwin-owner@xxxxxxxxxx] Im Auftrag von Mark Geisert
Gesendet: Montag, 5. Februar 2018 11:29
An: cygwin@xxxxxxxxxx
Betreff: Re: RPC clnt_create() adress already in use

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.

..mark

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple