Re: RPC clnt_create() adress already in use
PAULUS, Raimund, TI-ABN wrote: [...] Apologies for butting in, but there is one place you might look. It is not supported on the Cygwin lists; the few devs here already have overfull plates supporting current Windows OSs and Cygwin packages. It's the Cygwin Time Machine. Find it at http://www.crouchingtigerhiddenfruitbat.org/cygwin/timemachine.html HTH, ..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
Re: RPC clnt_create() adress already in use
On Mar 8 06:55, PAULUS, Raimund, TI-ABN wrote: > > Hello Corinna, > > is there still an earlier snapshot of the cygwin1.dll, that works > under Windows XP? I'd like to try to make the adjustments myself (in > net.cc). XP is deprecated since August 2016. No later snapshot supports XP. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
RE: RPC clnt_create() adress already in use
Hello Corinna, is there still an earlier snapshot of the cygwin1.dll, that works under Windows XP? I'd like to try to make the adjustments myself (in net.cc). Raimund -Ursprüngliche Nachricht- Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von Corinna Vinschen Gesendet: Dienstag, 27. Februar 2018 11:37 An: cygwin@cygwin.com Betreff: Re: RPC clnt_create() adress already in use On Feb 27 09:54, PAULUS, Raimund, TI-ABN wrote: > High Corinna, > > is it possible to get the patched cygwin1.dll for Cygwin 2.5.1? I have to > support several older Win XP SP3 boxes. Sorry, we only support the current Cygwin build and keep the next older version as fallback. It's just not feasible to support version branches like the Linux kernel does, given the low number of active participants in this project. Nothing keeps you from building your own, though. The patches should apply mostly clean. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: RPC clnt_create() adress already in use
High Mark, i did it already. Building cygwin1.dll in Cygwin 2.5.1 is ok, but using it delivers the message: "The procedure entry point CancelSynchronousIo could not be located in the dynamic link library KERNEL32.dll". It seems, i have to continue in using the old Cygwin 1.5.8 release for my Win XP SP3 boxes. Raimund -Ursprüngliche Nachricht- Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von Mark Geisert Gesendet: Mittwoch, 28. Februar 2018 07:00 An: cygwin@cygwin.com Betreff: Re: RPC clnt_create() adress already in use Corinna Vinschen wrote: > On Feb 27 09:54, PAULUS, Raimund, TI-ABN wrote: >> High Corinna, >> >> is it possible to get the patched cygwin1.dll for Cygwin 2.5.1? I have to >> support several older Win XP SP3 boxes. > > Sorry, we only support the current Cygwin build and keep the next > older version as fallback. It's just not feasible to support version > branches like the Linux kernel does, given the low number of active > participants in this project. > > Nothing keeps you from building your own, though. The patches should > apply mostly clean. > > > Corinna ...And there's a FAQ that tells how to build the Cygwin DLL. Provided you have installed all the necessary tools listed there, it is straightforward to do. https://cygwin.com/faq.html#faq.programming.building-cygwin Something to consider, ..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
Re: RPC clnt_create() adress already in use
Corinna Vinschen wrote: On Feb 27 09:54, PAULUS, Raimund, TI-ABN wrote: High Corinna, is it possible to get the patched cygwin1.dll for Cygwin 2.5.1? I have to support several older Win XP SP3 boxes. Sorry, we only support the current Cygwin build and keep the next older version as fallback. It's just not feasible to support version branches like the Linux kernel does, given the low number of active participants in this project. Nothing keeps you from building your own, though. The patches should apply mostly clean. Corinna ...And there's a FAQ that tells how to build the Cygwin DLL. Provided you have installed all the necessary tools listed there, it is straightforward to do. https://cygwin.com/faq.html#faq.programming.building-cygwin Something to consider, ..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
Re: RPC clnt_create() adress already in use
On Feb 27 09:54, PAULUS, Raimund, TI-ABN wrote: > High Corinna, > > is it possible to get the patched cygwin1.dll for Cygwin 2.5.1? I have to > support several older Win XP SP3 boxes. Sorry, we only support the current Cygwin build and keep the next older version as fallback. It's just not feasible to support version branches like the Linux kernel does, given the low number of active participants in this project. Nothing keeps you from building your own, though. The patches should apply mostly clean. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: RPC clnt_create() adress already in use
High Corinna, is it possible to get the patched cygwin1.dll for Cygwin 2.5.1? I have to support several older Win XP SP3 boxes. Raimund -Ursprüngliche Nachricht- Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von Corinna Vinschen Gesendet: Dienstag, 6. Februar 2018 15:20 An: cygwin@cygwin.com Betreff: Re: RPC clnt_create() adress already in use On Feb 6 11:29, PAULUS, Raimund, TI-ABN wrote: > On Feb 5 15:06, Corinna Vinschen wrote: > > On Feb 5 14:34, Corinna Vinschen wrote: > > > On Feb 5 12:26, Corinna Vinschen wrote: > > > > [...] > > > > What potential solutions to this problem do we have? > > > > > > > > - 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. > > > > > > > > - DisconnectEx? Never tried this Winsock extension but it might be > > > > worth a shot. > > > > I think I have a very simple solution for the scenario which calls > > bindresvport with port number. Still looking for a solution for the > > second problem... > > I've pushed a few patches and uploaded new developer snapshots to > https://cygwin.com/snapshots. Please give them a try. > > with the snapshot of cygwin1.dll and using bindresvport() from Cygwin > for libtirpc (instead of the original bindresvport() from libtirpc) > all my testcases work without error. > > Many thanks > Raimund Thanks for testing. Please note that this should work most of the time, but is still not 100% foolproof. There's a systematic race between checking existing connections and calling bind which can't be easily worked around by Cygwin. Still, should be better than before :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: RPC clnt_create() adress already in use
Corinna Vinschen wrote: On Feb 6 11:29, PAULUS, Raimund, TI-ABN wrote: On Feb 5 15:06, Corinna Vinschen wrote: [...] I've pushed a few patches and uploaded new developer snapshots to https://cygwin.com/snapshots. Please give them a try. with the snapshot of cygwin1.dll and using bindresvport() from Cygwin for libtirpc (instead of the original bindresvport() from libtirpc) all my testcases work without error. Many thanks Raimund Thanks for testing. Please note that this should work most of the time, but is still not 100% foolproof. There's a systematic race between checking existing connections and calling bind which can't be easily worked around by Cygwin. Still, should be better than before :} Great to read this latest status. I'll shortly submit a libtirpc patch to stub out its own version of bindresvport() in favor of Cygwin's version. Thanks all, ..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
Re: RPC clnt_create() adress already in use
On Feb 6 11:29, PAULUS, Raimund, TI-ABN wrote: > On Feb 5 15:06, Corinna Vinschen wrote: > > On Feb 5 14:34, Corinna Vinschen wrote: > > > On Feb 5 12:26, Corinna Vinschen wrote: > > > > [...] > > > > What potential solutions to this problem do we have? > > > > > > > > - 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. > > > > > > > > - DisconnectEx? Never tried this Winsock extension but it might be > > > > worth a shot. > > > > I think I have a very simple solution for the scenario which calls > > bindresvport with port number. Still looking for a solution for the > > second problem... > > I've pushed a few patches and uploaded new developer snapshots to > https://cygwin.com/snapshots. Please give them a try. > > with the snapshot of cygwin1.dll and using bindresvport() from Cygwin > for libtirpc (instead of the original bindresvport() from libtirpc) > all my testcases work without error. > > Many thanks > Raimund Thanks for testing. Please note that this should work most of the time, but is still not 100% foolproof. There's a systematic race between checking existing connections and calling bind which can't be easily worked around by Cygwin. Still, should be better than before :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: RPC clnt_create() adress already in use
Hello Corinna, with the snapshot of cygwin1.dll and using bindresvport() from Cygwin for libtirpc (instead of the original bindresvport() from libtirpc) all my testcases work without error. Many thanks Raimund -Ursprüngliche Nachricht- Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von Corinna Vinschen Gesendet: Montag, 5. Februar 2018 21:15 An: cygwin@cygwin.com Betreff: Re: RPC clnt_create() adress already in use On Feb 5 15:06, Corinna Vinschen wrote: > On Feb 5 14:34, Corinna Vinschen wrote: > > On Feb 5 12:26, Corinna Vinschen wrote: > > > 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 != 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. > > > > 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. > > > > > > - DisconnectEx? Never tried this Winsock extension but it might be > > > worth a shot. > > I think I have a very simple solution for the scenario which calls > bindresvport with port number. Still looking for a solution for the > second problem... I've pushed a few patches and uploaded new developer snapshots to https://cygwin.com/snapshots. Please give them a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: RPC clnt_create() adress already in use
On Feb 5 15:06, Corinna Vinschen wrote: > On Feb 5 14:34, Corinna Vinschen wrote: > > On Feb 5 12:26, Corinna Vinschen wrote: > > > 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 != 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. > > > > 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. > > > > > > - DisconnectEx? Never tried this Winsock extension but it might be > > > worth a shot. > > I think I have a very simple solution for the scenario which calls > bindresvport with port number. Still looking for a solution for > the second problem... I've pushed a few patches and uploaded new developer snapshots to https://cygwin.com/snapshots. Please give them a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: RPC clnt_create() adress already in use
Hi Mark and Corinna, i use my program in a production environment running 24 hours a day. Therefore it must be as stable as possible and I have different test scenarios. Normally the program is the only Cygwin program running at this time. It is running only for a short time for data exchange with a linux server. Subsequently an other program (not Cygwin) does the rest of the job with the transferred data. After some seconds (or minutes) the other program starts my program again for data exchange. My program is started by a VB-script (windows script host) or a DOS shell script but never in the bash. Raimund -Ursprüngliche Nachricht- Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von Mark Geisert Gesendet: Montag, 5. Februar 2018 11:29 An: cygwin@cygwin.com Betreff: Re: RPC clnt_create() adress already in use PAULUS, Raimund, TI-ABN wrote: > Hello Mark, > > unfortunately i must correct my statement from Friday. > The program works, but only if the connections to the server are established > 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 connection. 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 establish 20 connections and the allocated port numbers were interleaved. Are you running your test programs directly from a Windows Command Prompt or from one of the Cygwin shells like bash? > Actually only our approaches in the original bindresvport() seem to work 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? 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 just different strategies for avoiding a port collision, with different chances of working. Libtirpc's original approach is essentially to have a range of port numbers 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 work when you're calling bindresvport() multiple times within one program because it starts from the same port number each time. 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 same time.. but there is a chance of port number collision between the programs. 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 multiple calls in one program. So we need to nail down why it doesn't seem to work 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 -- 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
Re: RPC clnt_create() adress already in use
On Feb 5 14:34, Corinna Vinschen wrote: > On Feb 5 12:26, Corinna Vinschen wrote: > > 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 != 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. > > 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. > > > > - DisconnectEx? Never tried this Winsock extension but it might be > > worth a shot. I think I have a very simple solution for the scenario which calls bindresvport with port number. Still looking for a solution for the second problem... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: RPC clnt_create() adress already in use
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 multiple > > 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 scenario. > > 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 != 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. 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. > > - DisconnectEx? Never tried this Winsock extension but it might be > worth a shot. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: RPC clnt_create() adress already in use
On Feb 5 02:29, Mark Geisert wrote: > PAULUS, Raimund, TI-ABN wrote: > > Hello Mark, > > > > unfortunately i must correct my statement from Friday. > > The program works, but only if the connections to the server are > > established 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 connection. > > 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 establish > 20 connections and the allocated port numbers were interleaved. > > Are you running your test programs directly from a Windows Command Prompt or > from one of the Cygwin shells like bash? > > > Actually only our approaches in the original bindresvport() seem to work > > 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? > > 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 just > different strategies for avoiding a port collision, with different chances > of working. > > Libtirpc's original approach is essentially to have a range of port numbers > 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 work > when you're calling bindresvport() multiple times within one program because > it starts from the same port number each time. > > 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 same > time.. but there is a chance of port number collision between the programs. > > 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 multiple > 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 scenario. 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 != 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: RPC clnt_create() adress already in use
PAULUS, Raimund, TI-ABN wrote: Hello Mark, unfortunately i must correct my statement from Friday. The program works, but only if the connections to the server are established 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 connection. 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 establish 20 connections and the allocated port numbers were interleaved. Are you running your test programs directly from a Windows Command Prompt or from one of the Cygwin shells like bash? Actually only our approaches in the original bindresvport() seem to work 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? 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 just different strategies for avoiding a port collision, with different chances of working. Libtirpc's original approach is essentially to have a range of port numbers 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 work when you're calling bindresvport() multiple times within one program because it starts from the same port number each time. 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 same time.. but there is a chance of port number collision between the programs. 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 multiple calls in one program. So we need to nail down why it doesn't seem to work 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
Re: RPC clnt_create() adress already in use
Hello Mark,
unfortunately i must correct my statement from Friday.
The program works, but only if the connections to the server are established 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 connection.
Actually only our approaches in the original bindresvport() seem to work 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?
Greetings
Raimund
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
PAULUS, Raimund, TI-ABN
Gesendet: Freitag, 2. Februar 2018 13:58
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use
Hi Mark,
it works. Maybe it's the best solution for the problem.
Greetings
Raimund
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
Mark Geisert
Gesendet: Freitag, 2. Februar 2018 09:11
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use
Mark Geisert wrote:
> Corinna Vinschen wrote:
>> On Jan 31 00:15, Mark Geisert wrote:
>>> 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:
>>>> [...]
> [...]
>>
>> I'm a bit puzzled here in terms of using your own bindresvport.
>> Cygwin implements bindresvport{_sa} for quite some time, 2006 or earlier.
>
> Yeesh; I did not know that. Thanks for pointing that out. So that
> means there's another possible way to try solving the OP's issue: by
> using Cygwin's
> bindresvport* in place of the one supplied with libtirpc.
>
> If we see the OP's issue with Cygwin's bindresvport*, I think it makes
> more sense to patch libtirpc than to change Cygwin's bindresvport*.
> The crux of OP's issue is that libtirpc's code expects to see
> EADDRINUSE errors from bind() whereas on Cygwin they aren't often seen until
> you connect().
>
> I'll look into using Cygwin's bindresvport() in the next day or two.
My testing shows that OP's original issue goes away when libtirpc is compiled
to use Cygwin's bindresvport() directly rather than using its own version of
that function.
Raimund, could you try this newest possible solution? Before the first
#include in bindresvport.c, add the line
#ifndef __CYGWIN__
and at the end of the file, add the line
#endif
Then rebuild your libtirpc and your test programs linking against it, then run
your tests. If this proves to solve your original problem then I'll submit a
patch of libtirpc to the Cygwin package maintainer.
Thank 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
Re: RPC clnt_create() adress already in use
Hi Mark,
it works. Maybe it's the best solution for the problem.
Greetings
Raimund
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
Mark Geisert
Gesendet: Freitag, 2. Februar 2018 09:11
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use
Mark Geisert wrote:
> Corinna Vinschen wrote:
>> On Jan 31 00:15, Mark Geisert wrote:
>>> 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:
>>>> [...]
> [...]
>>
>> I'm a bit puzzled here in terms of using your own bindresvport.
>> Cygwin implements bindresvport{_sa} for quite some time, 2006 or earlier.
>
> Yeesh; I did not know that. Thanks for pointing that out. So that
> means there's another possible way to try solving the OP's issue: by
> using Cygwin's
> bindresvport* in place of the one supplied with libtirpc.
>
> If we see the OP's issue with Cygwin's bindresvport*, I think it makes
> more sense to patch libtirpc than to change Cygwin's bindresvport*.
> The crux of OP's issue is that libtirpc's code expects to see
> EADDRINUSE errors from bind() whereas on Cygwin they aren't often seen until
> you connect().
>
> I'll look into using Cygwin's bindresvport() in the next day or two.
My testing shows that OP's original issue goes away when libtirpc is compiled
to use Cygwin's bindresvport() directly rather than using its own version of
that function.
Raimund, could you try this newest possible solution? Before the first
#include in bindresvport.c, add the line
#ifndef __CYGWIN__
and at the end of the file, add the line
#endif
Then rebuild your libtirpc and your test programs linking against it, then run
your tests. If this proves to solve your original problem then I'll submit a
patch of libtirpc to the Cygwin package maintainer.
Thank 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
Re: RPC clnt_create() adress already in use
Mark Geisert wrote:
Corinna Vinschen wrote:
On Jan 31 00:15, Mark Geisert wrote:
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:
[...]
[...]
I'm a bit puzzled here in terms of using your own bindresvport. Cygwin
implements bindresvport{_sa} for quite some time, 2006 or earlier.
Yeesh; I did not know that. Thanks for pointing that out. So that means there's
another possible way to try solving the OP's issue: by using Cygwin's
bindresvport* in place of the one supplied with libtirpc.
If we see the OP's issue with Cygwin's bindresvport*, I think it makes more
sense to patch libtirpc than to change Cygwin's bindresvport*. The crux of OP's
issue is that libtirpc's code expects to see EADDRINUSE errors from bind()
whereas on Cygwin they aren't often seen until you connect().
I'll look into using Cygwin's bindresvport() in the next day or two.
My testing shows that OP's original issue goes away when libtirpc is compiled to
use Cygwin's bindresvport() directly rather than using its own version of that
function.
Raimund, could you try this newest possible solution? Before the first #include
in bindresvport.c, add the line
#ifndef __CYGWIN__
and at the end of the file, add the line
#endif
Then rebuild your libtirpc and your test programs linking against it, then run
your tests. If this proves to solve your original problem then I'll submit a
patch of libtirpc to the Cygwin package maintainer.
Thank 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
Re: RPC clnt_create() adress already in use
Corinna Vinschen wrote:
On Jan 31 00:15, Mark Geisert wrote:
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:
[...]
[...]
I'm a bit puzzled here in terms of using your own bindresvport. Cygwin
implements bindresvport{_sa} for quite some time, 2006 or earlier.
Yeesh; I did not know that. Thanks for pointing that out. So that means there's
another possible way to try solving the OP's issue: by using Cygwin's
bindresvport* in place of the one supplied with libtirpc.
If we see the OP's issue with Cygwin's bindresvport*, I think it makes more
sense to patch libtirpc than to change Cygwin's bindresvport*. The crux of OP's
issue is that libtirpc's code expects to see EADDRINUSE errors from bind()
whereas on Cygwin they aren't often seen until you connect().
I'll look into using Cygwin's bindresvport() in the next day or two.
Thanks all,
..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
Re: RPC clnt_create() adress already in use
On Jan 31 00:15, Mark Geisert wrote:
> 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:
> > [...]
> > 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?
I'm a bit puzzled here in terms of using your own bindresvport. Cygwin
implements bindresvport{_sa} for quite some time, 2006 or earlier.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: RPC clnt_create() adress already in use
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
Re: RPC clnt_create() adress already in use
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.
Raimund
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
Mark Geisert
Gesendet: Dienstag, 30. Januar 2018 10:05
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use
PAULUS, Raimund, TI-ABN wrote:
> Hi Mark,
> as Corinna wrote in the thread " Cygwin socket option SO_REUSEADDR operates
> unlike Linux", the cause for the problem in libtirpc is Microsofts
> implementation of socket handling. If i implement a simple socket client,
> that is not so much of an issue, because I call the functions separately and
> can handle the error. Moreover in this case bind() is not necessary.
> But in the case of libtirpc the implementation of clnttcp_create() determines
> the sequence of bind() and connect() for the local port and you cannot
> correct the error of bind() after the call of connect(). Therefore I think
> best is to set the port number to zero (port = 0) before the call to bind().
>
> Raimund
>
>
> -Ursprüngliche Nachricht-
> Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im
> Auftrag von PAULUS, Raimund, TI-ABN
> Gesendet: Dienstag, 9. Januar 2018 09:14
> An: cygwin@cygwin.com
> Betreff: WG: AW: RPC clnt_create() adress already in use
[...]
Hi Raimund,
Where, exactly, would you set the port number to zero? I can imagine how this
would solve the problem you're seeing but I'm concerned about other use cases.
It also seems a little odd to me we'd be making a Cygwin-specific patch rather
than "fixing" Cygwin itself so the patch would not be necessary. But I don't
feel strongly either way here. libtirpc already has Cygwin-specific patches.
..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
/*
* Copyright (c) 2009, Sun Microsystems, Inc.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
* - Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
* - Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
* - Neither the name of Sun Microsystems, Inc. nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
Re: RPC clnt_create() adress already in use
PAULUS, Raimund, TI-ABN wrote: Hi Mark, as Corinna wrote in the thread " Cygwin socket option SO_REUSEADDR operates unlike Linux", the cause for the problem in libtirpc is Microsofts implementation of socket handling. If i implement a simple socket client, that is not so much of an issue, because I call the functions separately and can handle the error. Moreover in this case bind() is not necessary. But in the case of libtirpc the implementation of clnttcp_create() determines the sequence of bind() and connect() for the local port and you cannot correct the error of bind() after the call of connect(). Therefore I think best is to set the port number to zero (port = 0) before the call to bind(). Raimund -Ursprüngliche Nachricht- Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von PAULUS, Raimund, TI-ABN Gesendet: Dienstag, 9. Januar 2018 09:14 An: cygwin@cygwin.com Betreff: WG: AW: RPC clnt_create() adress already in use [...] Hi Raimund, Where, exactly, would you set the port number to zero? I can imagine how this would solve the problem you're seeing but I'm concerned about other use cases. It also seems a little odd to me we'd be making a Cygwin-specific patch rather than "fixing" Cygwin itself so the patch would not be necessary. But I don't feel strongly either way here. libtirpc already has Cygwin-specific patches. ..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
Re: RPC clnt_create() adress already in use
Hi Mark, as Corinna wrote in the thread " Cygwin socket option SO_REUSEADDR operates unlike Linux", the cause for the problem in libtirpc is Microsofts implementation of socket handling. If i implement a simple socket client, that is not so much of an issue, because I call the functions separately and can handle the error. Moreover in this case bind() is not necessary. But in the case of libtirpc the implementation of clnttcp_create() determines the sequence of bind() and connect() for the local port and you cannot correct the error of bind() after the call of connect(). Therefore I think best is to set the port number to zero (port = 0) before the call to bind(). Raimund -Ursprüngliche Nachricht- Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von PAULUS, Raimund, TI-ABN Gesendet: Dienstag, 9. Januar 2018 09:14 An: cygwin@cygwin.com Betreff: WG: AW: RPC clnt_create() adress already in use Hi Mark, i have just tested it with the client-program from my email from December 29. The server-program is running on a linux-machine (SuSE Enterprise). I compiled and linked the client.exe in Cygwin 1.5.18 on a PC with Windows XP SP3 and it works (loop 100 times). It was running in the bash-shell. Thereafter I copied the client.exe to a Laptop with Windows 7 Home Premium. I started the program from the command prompt (cmd.exe) because rxvt doesn't work. The program works (loop 100 times). Greetings Raimund -Ursprüngliche Nachricht- Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von Mark Geisert Gesendet: Dienstag, 9. Januar 2018 05:52 An: cygwin@cygwin.com Betreff: Re: AW: RPC clnt_create() adress already in use Hi Raimund, I think I might have an idea where the root cause is. But first I want to revisit your very first email on this subject, from last September 22. You mentioned test results from various Cygwin versions vs various Windows versions. Are you absolutely sure your test program ran correctly on Cygwin 1.5.18 on *both* Windows XP and Windows 7? The reason I ask is that Windows' handling of socket option SO_REUSEADDR has changed over time and Cygwin has had to make accommodations to keep up. There might possibly be a need to revisit this within Cygwin. I want to test a possible solution within the Cygwin DLL on my test machine but it has another two days to go on a factorization problem it's running (under Cygwin). So I will respond again after I test. Thank 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 -- 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
Re: RPC clnt_create() adress already in use
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
--> 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 Cygw
Re: RPC clnt_create() adress already in use
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
xdr.h (typedefs where missed):
#include
--> typedef __uint64_t u_quad_t;
--> typedef __int64_t quad_t;
My compile-flags: -D_GNU_SOURCE -D__GLIBC__ -D__linux__
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;
}
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).
Greetings
Raimund
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
Mark Geisert
Gesendet: Mittwoch, 22. November 2017 22:55
An: cygwin@cygwin.com
Betreff: Re: WG: RPC clnt_create() adress already in use
(3rd attempt at sending this)
PAULUS, Raimund, TI-ABN wrote:
> Hello Mark,
>
> is there any news with respect to libtirpc? Very important: I need it in
> Cygwin 2.5.1.
I neglected to report what I found; sorry for that. The difference(s) between
the vanilla libtirpc 1.0.1 that you downloaded and the one supplied by Cygwin
are due to the patches applied as part of the Cygwin build. If you have the
Cygwin package's source downloaded and unpacked with 'cygport prep' you can
find these patches in /usr/src/libtirpc-1.0.1-1.src.
I noticed one of the patches is a security fix. I suspect one or more of these
patches are causing the difficulty you're having but I don't know enough about
RPC in general to set up a test environment and can't devote time to digging
further. This is as far as I can go. Apologies again for not stating this.
Regards,
..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-s
Re: RPC clnt_create() adress already in use
PAULUS, Raimund, TI-ABN wrote: Hello Mark, i downloaded the sources of libtirpc from this url: https://sourceforge.net/projects/libtirpc/files/libtirpc/1.0.1/ and unpacked it in the local subdirectory libtirpc-1.0.1. I had to make the following changes: libtirpc-1.0.1/src/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 libtirpc-1.0.1/tirpc/rpc/xdr.h (typedefs where missed): --> #include --> typedef __uint64_t u_quad_t; --> typedef __int64_t quad_t; I linked the necessary source files with my testprogram: gcc -D__GLIBC__ -D__linux__ -I/c/dh-progs/tstdir/libtirpc-1.0.1/tirpc \ tst_rpc.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_bcast.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_dg.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_generic.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_perror.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_vc.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/rpc_callmsg.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/rpc_commondata.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/rpc_generic.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/rpc_prot.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/rpcb_clnt.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/rpcb_prot.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr_array.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr_mem.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr_rec.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr_reference.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/getnetconfig.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/getnetpath.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/auth_none.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/auth_unix.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/authunix_prot.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/mt_misc.c \ /c/dh-progs/tstdir/libtirpc-1.0.1/src/debug.c \ -o tst_rpc-libtirpc-1-0-1 The program works perfectly (no errors is test cases 1 and 2). I assume, there must be a difference between the downloaded lib-files and the Cygwin-libtirpc. Thank you Raimund for debugging this to the root cause. Cygwin claims to be providing libtirpc 1.0.1 so I suspect you're correct about the cause. I will figure out what the differences are and take the issue up with the Cygwin libtirpc maintainer. Congrats on solving the problem yourself! Thanks again, ..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
Re: RPC clnt_create() adress already in use
Hello Mark,
i downloaded the sources of libtirpc from this url:
https://sourceforge.net/projects/libtirpc/files/libtirpc/1.0.1/ and unpacked it
in the local subdirectory libtirpc-1.0.1.
I had to make the following changes:
libtirpc-1.0.1/src/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
libtirpc-1.0.1/tirpc/rpc/xdr.h (typedefs where missed):
--> #include
--> typedef __uint64_t u_quad_t;
--> typedef __int64_t quad_t;
I linked the necessary source files with my testprogram:
gcc -D__GLIBC__ -D__linux__ -I/c/dh-progs/tstdir/libtirpc-1.0.1/tirpc \
tst_rpc.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_bcast.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_dg.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_generic.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_perror.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/clnt_vc.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/rpc_callmsg.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/rpc_commondata.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/rpc_generic.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/rpc_prot.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/rpcb_clnt.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/rpcb_prot.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr_array.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr_mem.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr_rec.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/xdr_reference.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/getnetconfig.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/getnetpath.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/auth_none.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/auth_unix.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/authunix_prot.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/mt_misc.c \
/c/dh-progs/tstdir/libtirpc-1.0.1/src/debug.c \
-o tst_rpc-libtirpc-1-0-1
The program works perfectly (no errors is test cases 1 and 2).
I assume, there must be a difference between the downloaded lib-files and the
Cygwin-libtirpc.
Raimund Paulus
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
Mark Geisert
Gesendet: Mittwoch, 27. September 2017 11:50
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use
Hello Raimund,
Let's keep this on the mailing list please.
PAULUS, Raimund, TI-ABN wrote:
> 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 = 0;
> bool bool_ret = clnt_control(cl, CLGET_FD, &fd); if(bool_ret == true) {
> printf("fd: %d\n", fd);
>
> int enable = 1;
> retval = 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
> setsockopt() would be valid only during the process is running (my test
> scenarios 1 and 2).
> But it wouldn't change anything regarding my test scenario 3 (several
> restarts).
>
> Raimund
I looked through the libtirpc source code and nowhere is SO_REUSEADDR being
set.
You are on the right track with how to do it, but by the time clnt_create()
returns to you it is already too late. As far as I can tell there is no way to
get access to the socket between the time it's created within libtirpc and the
time it's made available to you by clnt_create().
I did try running your testcase (thanks for supplying that) but I don't have a
local machine running RPC services and don't wish to poke at random machines on
the Internet ;-). I had to compile it as so:
gcc -g -o test_rpc -I/usr/include/tirpc test_rpc.c -ltirpc You are taking
care to compile against the correct RPC-package includes and link against the
correct RPC-package libraries, yes?
Speculation: There might be a way to decompose what clnt_create() does into
other libtirpc functions that accomplish the same thing, but in smaller pieces
such that you could set the socket option before bind() is called. That would
be a fair amount of work though and given my cursory look at the source I don't
know if it's even possible.
..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
Re: RPC clnt_create() adress already in use
Hello Mark,
i compiled and linked just as you.
As i mentioned in an other email, if I use socket-connections in the same
manner with a socket-service, in don't need to setsockopt(.., SO_REUSEADDR,
...) and it works.
Raimund
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
Mark Geisert
Gesendet: Mittwoch, 27. September 2017 11:50
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use
Hello Raimund,
Let's keep this on the mailing list please.
PAULUS, Raimund, TI-ABN wrote:
> 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 = 0;
> bool bool_ret = clnt_control(cl, CLGET_FD, &fd); if(bool_ret == true) {
> printf("fd: %d\n", fd);
>
> int enable = 1;
> retval = 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
> setsockopt() would be valid only during the process is running (my test
> scenarios 1 and 2).
> But it wouldn't change anything regarding my test scenario 3 (several
> restarts).
>
> Raimund
I looked through the libtirpc source code and nowhere is SO_REUSEADDR being
set.
You are on the right track with how to do it, but by the time clnt_create()
returns to you it is already too late. As far as I can tell there is no way to
get access to the socket between the time it's created within libtirpc and the
time it's made available to you by clnt_create().
I did try running your testcase (thanks for supplying that) but I don't have a
local machine running RPC services and don't wish to poke at random machines on
the Internet ;-). I had to compile it as so:
gcc -g -o test_rpc -I/usr/include/tirpc test_rpc.c -ltirpc You are taking
care to compile against the correct RPC-package includes and link against the
correct RPC-package libraries, yes?
Speculation: There might be a way to decompose what clnt_create() does into
other libtirpc functions that accomplish the same thing, but in smaller pieces
such that you could set the socket option before bind() is called. That would
be a fair amount of work though and given my cursory look at the source I don't
know if it's even possible.
..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
Re: RPC clnt_create() adress already in use
Hello Raimund,
Let's keep this on the mailing list please.
PAULUS, Raimund, TI-ABN wrote:
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 = 0;
bool bool_ret = clnt_control(cl, CLGET_FD, &fd); if(bool_ret == true) {
printf("fd: %d\n", fd);
int enable = 1;
retval = 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 setsockopt()
would be valid only during the process is running (my test scenarios 1 and 2).
But it wouldn't change anything regarding my test scenario 3 (several restarts).
Raimund
I looked through the libtirpc source code and nowhere is SO_REUSEADDR being set.
You are on the right track with how to do it, but by the time clnt_create()
returns to you it is already too late. As far as I can tell there is no way to
get access to the socket between the time it's created within libtirpc and the
time it's made available to you by clnt_create().
I did try running your testcase (thanks for supplying that) but I don't have a
local machine running RPC services and don't wish to poke at random machines on
the Internet ;-). I had to compile it as so:
gcc -g -o test_rpc -I/usr/include/tirpc test_rpc.c -ltirpc
You are taking care to compile against the correct RPC-package includes and link
against the correct RPC-package libraries, yes?
Speculation: There might be a way to decompose what clnt_create() does into
other libtirpc functions that accomplish the same thing, but in smaller pieces
such that you could set the socket option before bind() is called. That would
be a fair amount of work though and given my cursory look at the source I don't
know if it's even possible.
..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
Re: Re: RPC clnt_create() adress already in use
Hello Mark Geisert,
i have an other testprogram making the connections not using RPC. Instead it
uses socket-connections directly (without setsockopt()). The operations in the
program are the same as in my RPC-testprogram.
But now the program works perfectly (in Cygwin 1.5.18 and Cygwin 2.5.1). There
are no errors.
Therefore I think the cause for the error in my RPC-testprogram is not the
socket-handling but the RPC-handling in libtirpc. But I have no idea to control
the RPC-handling to avoid the error.
Raimund Paulus
Source of socket-testprogram:
/*=*/
/* Include-Files */
/*=*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/*===*/
/* global definitions */
/*===*/
// max. nr. of connection attempts
#define CONNECT_MAX (int)3
// waittime for connection
#define CONNECT_WAITTIME (unsigned int)5
char host_ip[] = "128.2.9.1"; // IP host
int svc_port= 49154; // port-nr. for service
char local_errmsg[512];
/*===*/
/* prototyping */
/*===*/
// function for open a connection
int SVC_Open(void);
// function for close a connection
int SVC_Close(int fd_svc);
/**/
/* main-program */
/**/
int main(int argc, char *argv[])
{
int retval = 0;
int sleeptime = 0;
int fd_sock = 0;// socket descriptor
// read sleep-Time
if(argc < 2)
{
printf("no input for sleep-Time --> default\n");
sleeptime = 10;
}
else
{
char *endptr;
errno = 0;
sleeptime = (int)strtol(argv[1], &endptr, 10);
if ( (errno == ERANGE && (sleeptime == LONG_MAX || sleeptime == LONG_MIN))
|| (errno != 0 && sleeptime == 0))
{
fprintf(stderr, "input for sleeptime (%s) invalid: %s\n",
argv[1], strerror(errno));
exit(1);
}
}
printf("sleep-Time = %d \n", sleeptime);
// loop for 20 connection
int i;
for(i=0; i<20; i++)
{
fd_sock = SVC_Open();
if(retval < 0)
break;
printf("connection nr. %d established \n", i+1);
sleep(1);
retval = SVC_Close(fd_sock);
if(retval < 0)
break;
printf("connection closed\n");
printf("wait for %d sec.\n", sleeptime);
sleep(sleeptime);
}
if(retval < 0)
fprintf(stderr, "%s\n", local_errmsg);
return(0);
}
int SVC_Open(void)
{
int nr_connects = 0;// nr of connection attempts
int retval = 0;
struct sockaddr_in server_address;
int fd_svc = -1;// socket descriptor
// get socket descriptor
errno = 0;
fd_svc = socket (AF_INET, SOCK_STREAM, 0);
if (fd_svc < 0)
{
sprintf(local_errmsg, "socket(): %s", strerror(errno));
return(-1);
}
// initializing struct
bzero ((char *) &server_address, sizeof (server_address));
server_address.sin_family = AF_INET;
server_address.sin_addr.s_addr = inet_addr(host_ip);
server_address.sin_port = htons(svc_port);
errno = 0;
// establish connection; if error --> retry max. CONNECT_MAX times
for(nr_connects = 0; nr_connects < CONNECT_MAX; nr_connects++)
{
printf("connection attempt nr. %d\n",nr_connects+1);
retval = connect (fd_svc,
(struct sockaddr *) &server_address,
sizeof (server_address));
if (retval < 0)
{
sprintf(local_errmsg, "connect(): %s", strerror(errno));
if(nr_connects < CONNECT_MAX)
{
fprintf(stderr, "%s\n", local_errmsg);
sleep(CONNECT_WAITTIME);
}
continue;
}
else
break;
} // end for()
// error handling (no success)
if (retval < 0)
{
close(fd_svc);
return(retval);
}
else
return(fd_svc);
}
int SVC_Close(int fd_svc)
{
int retval = 0;
if(fd_svc > 0)
{
errno = 0;
retval = close(fd_svc);
if(retval < 0)
sprintf(local_errmsg, "close(): %s", strerror(errno));
}
return(retval);
}
-----Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
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 (Windows XP
> SP3, in the past Windows NT too). On the Linux-Server RPC-Services (Remote
> Procedure Call) are running, one service for one Windows-PC each. To build
> the RPC-clients on the Windows-boxes, I used Cygwin 1.5.18 and actually
> Cygwin 2.5.1 (because we now have Windows 7 too).
>
> The RPC-Clie
Re: RPC clnt_create() adress already in use
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 = 0;
bool bool_ret = clnt_control(cl, CLGET_FD, &fd); if(bool_ret == true) {
printf("fd: %d\n", fd);
int enable = 1;
retval = 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 setsockopt()
would be valid only during the process is running (my test scenarios 1 and 2).
But it wouldn't change anything regarding my test scenario 3 (several restarts).
Raimund
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von
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 (Windows XP
> SP3, in the past Windows NT too). On the Linux-Server RPC-Services (Remote
> Procedure Call) are running, one service for one Windows-PC each. To build
> the RPC-clients on the Windows-boxes, I used Cygwin 1.5.18 and actually
> 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 minutes.
>
> 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
> problems. Sometimes the RPC-Client cannot establish a connection to the
> server. 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 you're
getting, it might be due to a difference between libtirpc and the older librpc.
When a program binds a specific address and port to a socket, uses the socket
then later closes it, the system keeps the tuple in a "locked"
state until enough time has passed for the other end of the connection to
notice 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 safety
mechanism.
If you wish to override that behavior, you set a specific option SO_REUSEADDR
on the socket with setsockopt() before you issue the bind(). Perhaps libtirpc
is not doing that, though librpc was doing that. Only way to know is to
examine the source to both libraries. It's possible an strace of a broken
session compared to an strace of a working session might shed some light.
..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
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 (Windows XP SP3, in the past Windows NT too). On the Linux-Server RPC-Services (Remote Procedure Call) are running, one service for one Windows-PC each. To build the RPC-clients on the Windows-boxes, I used Cygwin 1.5.18 and actually 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 minutes. 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 problems. Sometimes the RPC-Client cannot establish a connection to the server. 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 you're getting, it might be due to a difference between libtirpc and the older librpc. When a program binds a specific address and port to a socket, uses the socket then later closes it, the system keeps the tuple in a "locked" state until enough time has passed for the other end of the connection to notice 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 safety mechanism. If you wish to override that behavior, you set a specific option SO_REUSEADDR on the socket with setsockopt() before you issue the bind(). Perhaps libtirpc is not doing that, though librpc was doing that. Only way to know is to examine the source to both libraries. It's possible an strace of a broken session compared to an strace of a working session might shed some light. ..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
