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
