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=jFbz2UwfsWVObKAd1SENZNcq7G7sD6zdKNzKEU8G0GRvadTWWaWVv
	Xu+noDd6qgIQMv1aUBsP+zhmbrlOg45XTK/dn5XPW847ArTi/CAzlAhIi25xf/KB
	guW7tHud6hoyoVvRuAW6kWDbLdyL8tli5BvJl5LaNvnrI3vcSY9gr0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 5 Feb 2018 14:34:50 +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: <20180205133450.GJ2912@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> <20180205112617 DOT GB2912 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="Dzs2zDY0zgkG72+7"
Content-Disposition: inline
In-Reply-To: <20180205112617.GB2912@calimero.vinschen.de>
User-Agent: Mutt/1.9.1 (2017-09-22)

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

On Feb  5 12:26, Corinna Vinschen wrote:
> On Feb  5 02:29, Mark Geisert wrote:
> > 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 mult=
iple
> > calls in one program.  So we need to nail down why it doesn't seem to w=
ork
> > for you.
>=20
> Apart from all the above, there may still be a problem in the given scena=
rio.
>=20
> To reiterate the problem we observe:
>=20
> - socket()
> - setsockopt (SO_REUSEADDR)
> - bind() succeeds
> - connect() fails with EADDRINUSE while socket is still in TIME_WAIT
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> What potential solutions to this problem do we have?
>=20
> - bindresvport could enforce SO_EXCLUSIVEADDRUSE temporarily to make
>   sure bind fails.

Nope, no way.  Even enforcing SO_EXCLUSIVEADDRUSE results in the
second bind succeeding and the subsequent connect failing.  The
entire SO_REUSEADDR/SO_EXCLUSIVEADDRUSE semantics only works as
desired on the server side apparently

> - bindresvport could check every local address for being free prior
>   to calling bind.  However, there's a potential race here.
>=20
> - 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

--Dzs2zDY0zgkG72+7
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlp4XXoACgkQ9TYGna5E
T6BJEw/8Du4S5K8aUOwfVRUosL4qoGsE4PXMsMBLSsmWHVzh4huRiJoL8o67zzhW
ACsbKZYB3/mlBNNVt/MjPV7S+0Am4gMrQsqe29ai17Ffix9QKrQGqlwLwmQKDeaG
8O9LwC/7ERZpyxYOZOkZ9JZ1sWG1mHR/up9KkukpjCKBhkfYv3QLpnWT4SIuZF/V
9VONQL2uRPLtLtU66JwLcYZz35YBnX2Gs3pgZgzWZKRDtwfF2iyVCYkw2E0ceR9E
YxkgWayUypiWYeZN0Krs6wblaSMUfxC47uYbAoLqXNWA7qG0UlCqCBacCMuuJa70
MmkRzKM8wixLC5nn2V9UFY3hc6D/54RfDGxlb8XvIHhvdX4lMnNRJ7ITEIkxTkHz
3mlDiANlKTElt7CE7OfrPSXeAKA0KQGt/tMt7AKF1+HV9P2iCZn7czCrCBcNlMUn
DqiBQlY65b/GOAL8dD7YAmfMRxgyT9X4FOBwsi3EEj4MTuT7CSZIGGrj0so7UOc5
+TtT5MVbsPz7M5T0pBL+B0mFGw6xl1erh0W9DN4dj6U1qc6KrgOohiqm7UU757wV
7f15Y1RW15X99O8LUHYAc2g1vLUWo5glUJedlMppawjQ56DaVL6M27KbvKP4vIkQ
wQoVoQyKji1ogTy2I2mnSYC2QDXyi6xH879ZCvk1/yaRULoG1Kc=
=3JUH
-----END PGP SIGNATURE-----

--Dzs2zDY0zgkG72+7--