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=jg9WsOPH5CONJgIg
	1djC6c4xy0vI7yyER4oPZa0WvPYdhPp7gJjm6YubsaHT+7lwX2h/C1iiJrNAF0G+
	mMYmnn//Xvv7Y5qEliFHYwiyLhDFz/QmMwKx8DwMGD563vg8+WTdskYZyCdfZf0w
	Hbxgbo8zeaLLuOI4RbFVSAEcTNI=
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=29ZfaJeX11Lwg+PWpq+kk2
	g9ogI=; b=Ta0CZMNMGxJy1R7/40dpcyJbW0h+H3HB41c9pdrxLBZRoclXnZlRj8
	T6hcgGeThTHlYjZ9SzdQ6PcSEvjS2nahbgedJ6IJkhej/6gmArw0BXrhOz4XJh5W
	UtdI/fFEfoVHMD8c5/rFzSON/Mc0ZyeW3yeG421RNu9U1+jOUqRUw=
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=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=UD:msg00194.html, msg00194html, msg00194.html, treating
X-HELO:	m0.truegem.net
Subject:	Re: RPC clnt_create() adress already in use
To:	cygwin AT cygwin DOT com
References:	<59D90AF8D70E9740907BACDE2BCB520836E01220 AT RESW102 DOT resdom01 DOT local>
From:	Mark Geisert <mark AT maxrnd DOT com>
Message-ID:	<812cb3b6-9d28-971c-45eb-38421d817ca4@maxrnd.com>
Date:	Wed, 31 Jan 2018 00:15:16 -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:	<59D90AF8D70E9740907BACDE2BCB520836E01220@RESW102.resdom01.local>

PAULUS, Raimund, TI-ABN wrote:
> Hi Mark,
>
> in my email (https://sourceware.org/ml/cygwin/2017-12/msg00194.html) i described 2 approaches. I prefer  nr 1.
> Here the part of the source in bindresvport.c:
> ------------------------------------------------------------------------------------------------------------------
>         if (port == 0) {
>                 port = (getpid() % NPORTS) + STARTPORT;
>         }
>         res = -1;
>         errno = EADDRINUSE;
>
> /* fix for bind() */
> port = 0;
>                 again:
>         for (i = 0; i < nports; ++i) {
>                 *portp = htons(port++);
>                  if (port > endport)
>                         port = startport;
>                 res = bind(sd, sa, salen);
>                 if (res >= 0 || errno != EADDRINUSE)
>                         break;
>         }
>         if (i == nports && startport != LOWPORT) {
>             startport = LOWPORT;
>             endport = STARTPORT - 1;
>             nports = STARTPORT - LOWPORT;
>             port = LOWPORT + port % (STARTPORT - LOWPORT);
>             goto again;
>         }
>         mutex_unlock(&port_lock);
>
>         return (res);
> }
> -------------------------------------------------------------------------------------------------------
>
> This causes bind() to search an unused port. I use libtirpc with this fix since several weeks and it works for me. I don't know an other way (fixing Cygwin) to success.
> The RPC-client on my pc is started every few minutes and has to connect to the RPC-server.  Without the fix libtirpc is not usable and I have to use Cygwin 1.5.18 with the old librpc.
[...]

Hi Raimund,
Thanks for attaching the complete source for your modified bindresvport.c.  I 
had been treating your setting of port to 0 as a workaround rather than as a 
solution.  My misunderstanding.

We can't solve the issue that way because when bind() is called with a zeroed 
port number, it picks a random port number that's often outside the range of 
ports bindresvport() is supposed to return (i.e., a port between STARTPORT and 
ENDPORT).

I thought of something similar to your idea but obeying the bindresvport() 
semantics.  I add a static short value named 'usecount' to the function's local 
variables.  Mid-function, I have this code to choose a port number:
     if (port == 0) {
         port = ((getpid() + usecount++) % NPORTS) + STARTPORT;
     }

Can you try this with your testcase(s) and make sure it works 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 -