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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=HAKG9TFe59zHmgJUtHav+Bsy0mXqZnrzl9aJsFViKN9tbXf0h0SGA
	XCqEu1IRbajsB40RQW5SSmO47ZvflkOqoUvK0jDEjD8GnQzQcpkt0ZweAlJTNtzu
	DVzJsZLA3JKTxT9kl1odPA4GQbDfJDX+N3+nfhnIJrXtyVmzKfEiao=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=XHo21U05EiC97QpUMb+KRbNQhsI=; b=vtOonJZrTOdXaVtepsYt/QocptLn
	cI/LB9eLU+p2fOwvojdRvysuXsZvdTWeRnuZm/KajrJW9b++x1J5MeB/5kKribdA
	a1p6GbpBCUFdAy8MxoKI39BlaAX/2iIyw2y3OpgpDJTWePqiHi0dXqan7+Sv1vl6
	431hIqbEx4od+uw=
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=-101.9 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=nail, randomly, H*f:sk:59D90AF, Our
X-HELO:	drew.franken.de
Date:	Mon, 5 Feb 2018 12:26:17 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: RPC clnt_create() adress already in use
Message-ID:	<20180205112617.GB2912@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<59D90AF8D70E9740907BACDE2BCB520836E325EF AT RESW102 DOT resdom01 DOT local> <5b897ca4-9a7d-df90-e7a0-dbdedbd1f179 AT maxrnd DOT com>
MIME-Version:	1.0
In-Reply-To:	<5b897ca4-9a7d-df90-e7a0-dbdedbd1f179@maxrnd.com>
User-Agent:	Mutt/1.9.1 (2017-09-22)

--8GpibOaaTibBMecb
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb  5 02:29, Mark Geisert wrote:
> PAULUS, Raimund, TI-ABN wrote:
> > Hello Mark,
> >=20
> > unfortunately i must correct my statement from Friday.
> > The program works, but only if the connections to the server are establ=
ished 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 connectio=
n.
>=20
> 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 establ=
ish
> 20 connections and the allocated port numbers were interleaved.
>=20
> Are you running your test programs directly from a Windows Command Prompt=
 or
> from one of the Cygwin shells like bash?
>=20
> > Actually only our approaches in the original bindresvport() seem to wor=
k 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?
>=20
> 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 ju=
st
> different strategies for avoiding a port collision, with different chances
> of working.
>=20
> Libtirpc's original approach is essentially to have a range of port numbe=
rs
> 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 wo=
rk
> when you're calling bindresvport() multiple times within one program beca=
use
> it starts from the same port number each time.
>=20
> 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 s=
ame
> time.. but there is a chance of port number collision between the program=
s.
>=20
> 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 multip=
le
> 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 scenari=
o.

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 !=3D 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

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

--8GpibOaaTibBMecb
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlp4P1kACgkQ9TYGna5E
T6CFeBAAlUPAhJoozDSWg9cg6Kzo1vQ/+rxrC0H/aGfuoMzecNuoQn90QgKGzwUe
QrQLwMiF5CNbEfI9iPR3PtwyFvBSOpMHJP/3q1smwMu8avGciM+2wxDP1LilyfOG
67/odnUcR1tEIXBGYkgxO4Sve/7OsYeheAiyok8MxY8uNK/uiLRtrN147tTMEWs/
GxiS27whh2xJH/fTwJAdUWidjgz/UHuRW/AQ+5vsfJ1acEwCioH8ZxwRXkCyoJGr
r/xbm6y/jEuHeVchC+9TH3hyhQ0DU8dr++KVkCV+IybaesPHsRQatX5jxBuReHxC
fnKifPjOBMk1FbsO1c3ShJ4YK8b0PEJM+g0Wa2j1LRaopSVMMKqCneE5YmVzUhWF
UfA6CshLrhEUkv5q6VlvM8hsNiw0Cst7hy9uA5uUCIWsyktVdOMUPPMGbXd0flfU
8cV4UTAgFfEQhTfOzoTLh/dA+QRCcdBWwmKVLxVvW8YceZ1OYFbqnFbGnQrrpDKj
CFdUUU2ntgveiCa5rV00ZGfi7mA2xCMdx1niP9aMtezfwmifIxH2ru459YtTEM0T
vHhDY4KRpMlCfc5aSyFH3yUh2ROQOAmDM/ScCSrs45FP+3KWtuHGsVGCTQk9KAYK
x9WZWTLa2Tk1jPTuBrOZgWnl6mD4LQmYbaTiCk5Nw3A+SxfULHo=
=n1A+
-----END PGP SIGNATURE-----

--8GpibOaaTibBMecb--

- Raw text -