X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=NDYCuQkWK6RbhyvM
	E7olD2uFWUkxax9u9GhPi4NmzZ51hjoDLYdax+vJl0eMMOTEoJUnjiXr3KlZUNch
	RGbYhtnWLZ738E0Q8tbBeRMw/DHF9XgHkM0AzhXZ/cqtuvmOCHN0nOXXcz5zq409
	7GAsegDxxyltzMtHwCVa9TZCYYs=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=u4ysRKbhH+vgE6e+H2XJNo
	9I6nw=; b=H8JRKPl+OWCZfJh/KiDJFzoZhR5gUoXjUG6XFwBKAJhpVsNB3IufeI
	qhBM3RzZJXEcA/ogwNjavMoaTjoEbvdNIRx/qUycsm3CgX8/r9O8JFT1nC8XgGCH
	pcFMe784Ccz/iTFoO+kqcPtxd2kEEX4pEvH6Ta+qizqmXzvcDK7k8=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=nail, randomly, H*r:8.12.11, H*f:sk:59D90AF
X-HELO:	m0.truegem.net
Subject:	Re: RPC clnt_create() adress already in use
To:	cygwin AT cygwin DOT com
References:	<59D90AF8D70E9740907BACDE2BCB520836E325EF AT RESW102 DOT resdom01 DOT local>
From:	Mark Geisert <mark AT maxrnd DOT com>
Message-ID:	<5b897ca4-9a7d-df90-e7a0-dbdedbd1f179@maxrnd.com>
Date:	Mon, 5 Feb 2018 02:29:22 -0800
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
MIME-Version:	1.0
In-Reply-To:	<59D90AF8D70E9740907BACDE2BCB520836E325EF@RESW102.resdom01.local>

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

- Raw text -