From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96373 invoked by alias); 25 Sep 2017 06:44:35 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 95345 invoked by uid 89); 25 Sep 2017 06:44:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_60,CYGWIN_OWNER_BODY,GIT_PATCH_2,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=H*MI:local, H*M:local, adress, clnt_create X-HELO: mailrelay.dillinger.de Received: from mailrelayb.dillinger.de (HELO mailrelay.dillinger.de) (212.184.64.29) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Sep 2017 06:44:32 +0000 Received: from mailrelaya2.dillinger.de (mailrelaya [192.168.175.11]) by lin254mailrelayb.dillinger.de (Postfix) with ESMTP id 39643A34E for ; Mon, 25 Sep 2017 08:44:30 +0200 (CEST) Received: from lin275.int.shsservices.de (lin275 [172.18.32.6]) by mailrelaya2.dillinger.de (Postfix) with ESMTP id 744D624234A for ; Mon, 25 Sep 2017 08:51:11 +0200 (CEST) Received: from RESW102.resdom01.local (resw102.dillinger.de [172.18.22.102]) by lin275.int.shsservices.de (Postfix) with ESMTP id 1587CF3B22 for ; Mon, 25 Sep 2017 08:44:30 +0200 (CEST) Received: from RESW103.resdom01.local ([fe80::a480:c1ef:e5bb:a91b]) by RESW102.resdom01.local ([fe80::a883:3db9:4459:1159%15]) with mapi id 14.03.0279.002; Mon, 25 Sep 2017 08:44:29 +0200 From: "PAULUS, Raimund, TI-ABN" To: "'cygwin@cygwin.com'" Subject: Re: RPC clnt_create() adress already in use Date: Mon, 25 Sep 2017 06:44:00 -0000 Message-ID: <59D90AF8D70E9740907BACDE2BCB52083660696D@RESW103.resdom01.local> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00233.txt.bz2 Hallo Mark Geisert, many thanks for your answer. I supposed this too. I included in my source code the following function calls after clnt_create= (): int fd =3D 0; bool bool_ret =3D clnt_control(cl, CLGET_FD, &fd); if(bool_ret =3D=3D true)= { printf("fd: %d\n", fd); int enable =3D 1; retval =3D setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &enable, sizeof(int)); if(retval < 0) fprintf(stderr, "Fehler setsockopt(): %s\n", strerror(errno)); } The function clnt_control() delivers the socket of the RPC-Client-Handle. The result is the same as before. Moreover i think, the effect of setsockop= t() would be valid only during the process is running (my test scenarios 1 = and 2).=20 But it wouldn't change anything regarding my test scenario 3 (several resta= rts). Raimund -----Urspr=FCngliche Nachricht----- Von: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] Im Auftrag vo= n Mark Geisert Gesendet: Sonntag, 24. September 2017 11:49 An: cygwin@cygwin.com Betreff: Re: RPC clnt_create() adress already in use PAULUS, Raimund, TI-ABN wrote: > In our environment we have a Linux-Server and several Windows-PCs (Window= s XP SP3, in the past Windows NT too). On the Linux-Server RPC-Services (Re= mote Procedure Call) are running, one service for one Windows-PC each. To b= uild the RPC-clients on the Windows-boxes, I used Cygwin 1.5.18 and actuall= y Cygwin 2.5.1 (because we now have Windows 7 too). > > The RPC-Client (*.exe) on the Windows-box is started at any time by hand,= establishes a connection to the server (clnt_create), executes a few calls= to the server (clnt_call), closes the connection (clnt_destroy) and exits.= The time-interval between the program starts can be 10 seconds up to 2 min= utes. > > This worked over many years without any error (Cygwin 1.5.18). > Now I upgraded to Cygwin 2_5_1 (libtirpc instead librpc) and there are pr= oblems. Sometimes the RPC-Client cannot establish a connection to the serve= r. The error message from clnt_spcreateerror(): > > Remote system error - Address already in use > > I think it is "EADDRINUSE". I can only answer generally as I haven't tried your testcase and don't know= anything about either RPC library on Cygwin. If EADDRINUSE is the error y= ou're getting, it might be due to a difference between libtirpc and the old= er librpc.=20 When a program binds a specific address and port to a socket, uses the sock= et then later closes it, the system keeps the tuple in a "l= ocked"=20 state until enough time has passed for the other end of the connection to n= otice the connection's been closed. During that time, attempting to bind()= with the same address and port will result in EADDRINUSE. It's a TCP/IP s= afety mechanism. If you wish to override that behavior, you set a specific option SO_REUSEAD= DR on the socket with setsockopt() before you issue the bind(). Perhaps li= btirpc is not doing that, though librpc was doing that. Only way to know i= s to examine the source to both libraries. It's possible an strace of a br= oken session compared to an strace of a working session might shed some lig= ht. ..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 -- 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