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=Y8rnlkc9itndC6vn
	OTwgiN6xa7n48Y0tjQoa10USXArwR92xIV4sVtq0pZuDuBcJJnRhboDvqQUM+bT5
	RlPL+FJYjbWZWMYepjHMONXIS7RR8N8qefRbd4taNBBQcFHavwgCq8TbPcR76tLf
	wOfyLqp0Jdn546MXwHsYd0vIOHg=
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=x4hDDyv/yTcv+aeG7qREoR
	/UF4s=; b=E3R/ng1xzt+dUIRCoqmhR8XFgQE9YfkyucZHW0BNjfq04J0bcxdQm8
	2/HKL3q7Nf2dPPafFzIc09P9p9XlDJUiT8bFJNWOiHg+div55xHHS2czdk/CMtGm
	n0R7EqWYU4UxR9hhcgBY9yRYLuJFvmgfJdmr6Uws7k401QxkBMgLI=
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=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=compliment, aim, adress, connections
X-HELO:	m0.truegem.net
Subject:	Re: RPC clnt_create() adress already in use
To:	cygwin AT cygwin DOT com
References:	<59D90AF8D70E9740907BACDE2BCB520836C7DD89 AT RESW102 DOT resdom01 DOT local>
From:	Mark Geisert <mark AT maxrnd DOT com>
Message-ID:	<2bc825e4-9d9b-37b4-e8bd-23e26bfb08bc@maxrnd.com>
Date:	Wed, 27 Dec 2017 01:39:24 -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:	<59D90AF8D70E9740907BACDE2BCB520836C7DD89@RESW102.resdom01.local>

Hi Raimund,
Comments embedded below...

PAULUS, Raimund, TI-ABN wrote:
> Hello Mark,
>
> in my earlier tests the lib and header files for tirpc was still there from the Cygwin-installation. I think, this could influence the results of the tests.
> Therefore i removed these files. From now on i used only the downloaded files from sourceforge (https://sourceforge.net/projects/libtirpc/files/libtirpc/). I tested libtirpc-0.3.2, libtirpc-1.0.1 and libtirpc-1.0.2. The results for all releases are the same.
>
> I needed the following sources:
>
> auth_none.c, auth_unix.c, authunix_prot.c, bindresvport.c, clnt_bcast.c, clnt_dg.c, clnt_generic.c, clnt_perror.c, clnt_vc.c, debug.c, getnetconfig.c, getnetpath.c, mt_misc.c, rpc_callmsg.c, rpc_commondata.c, rpc_generic.c, rpc_prot.c, rpcb_clnt.c, rpcb_prot.c, xdr.c, xdr_array.c, xdr_float.c, xdr_reference.c,   xdr_rec.c, xdr_mem.c
>
> I had to change the following (already mentioned earlier):
>
> clnt_bcast.c
> (because POLLRDNORM, POLLRDBAND are already defined in /usr/include/sys/poll.h) :
>
> --> #ifndef POLLRDNORM
> # define POLLRDNORM     0x040           /* Normal data may be read.  */
> # define POLLRDBAND     0x080           /* Priority data may be read.  */
> --> #endif

Not only does /usr/include/sys/poll.h already define them, they're defined with 
different values.  Could be a red flag or a red herring; don't know yet.

> xdr.h (typedefs where missed):
>
> #include <rpc/types.h>
>
> --> typedef __uint64_t      u_quad_t;
> --> typedef __int64_t       quad_t;
>
>
> My compile-flags: -D_GNU_SOURCE -D__GLIBC__ -D__linux__

Just so I understand more fully: you are compiling with those options on Cygwin?

> If i build my test program with the sources above, the behavior is the same as with the Cygwin-libtirpc: the first RPC-connection is ok, the next call to clnt_create() delivers the error EADDRINUSE.
>
> The test program on a Linux-box works perfectly. With "netstat -n" you can see each connection from the client to the server creates a new pair of ports. On the server-side the pair is always the same (ports 111, 907). On the client-side however the ports differ from one connection to the other. When the connections are closed the ports remain in state TIME_WAIT. After a while they disappear.
>
> If the RPC-client (Cygwin) is running on a Windows-box, "netstat -n" shows the pair of ports for the first connection. The next connection attempt (clnt_create()) delivers: EADDRINUSE.
>
> In the sources you can see the following:
>
> clnt_create() calls the function bindresvport_sa() (in bindresvport.c). Here the port for the connection is determined:
>
> if (port == 0) {
>                 port = (getpid() % NPORTS) + STARTPORT;
> }

The idea there is to use a different port on each run of the program.  If you're 
looping around and reaching that code again with port==0, then yes you'll get 
the same port number each time because getpid() is not changing.

>
> and the socket is bound to the port:
>
> res = bind(sd, sa, salen);
>
> If this part is executed multiple times (loop) the port is always the same. The function bind() doesn't deliver an error (res = 0, maybe bind() doesn't work correctly?). Therefore the error is not detected until the call of  connect() in function clnt_vc_create() (in clnt_vc.c). But here you can not correct the port.
>
> I tried the following:
>
> The call of setsockopt(., SO_REUSEADDR, .) before bind() doesn't change anything. The error still occurs.
>
> I found 2 approaches to avoid the error:
>
> 1. Before the call to bind() set the port to 0 (port = 0). The following bind() searches an unused port.
>
> 2. Set the port to 0 (port = 0). Do not call bind(). Later the call to connect() searches an unused port.
>
> I tested the two methods and the behavior was the same as the Linux-client. It obviously works correctly.  But i'm not a network specialist and i don't know, if it's the best solution for the problem.
>
>
> Subsequently I downloaded the Cygwin-sources for libtirpc-0.3.2 and libtirpc-1.0.1. And here again, with the changes mentioned in the two approaches the RPC-connection works perfectly. The only difference her is: a connection does not create a pair of ports but only a single port (netstat -n).

I must compliment you; you are being very specific and detailed about what 
you're doing on the client end of the RPC connection.  But as I said in my last 
email, I don't know specifics about RPC implementation; I sort of know generally 
what RPC can do.

I don't know enough to set up an RPC test bed to try your client program 
locally.  *Unless* it's sufficient to run your client program and aim at the 
local machine even though it has no RPC server listening.  If that would 
demonstrate your issue, let me know and I'll have another look.  Otherwise, I 
would need to set up an RPC server on my Cygwin machine.  If you've done that on 
your Cygwin machine, what are the steps?  I think I can follow Unix-style 
instructions but will have to allow for Windows Firewall so if you've done this 
already on Cygwin your procedure would help a lot.
Thanks,

..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 -