mirza@magnus.ircc.ohio-state.edu (Khalid Mirza) (01/10/91)
I am using the KA9Q Internet Protocol Package at The Ohio State University for developing an internet FAX facility for IBM PCs. I have the following question about the software: While trying to establish a TCP socket connection, the "connect" routine does not time-out if the socket listener on the other end is not running. Is there any way to include the time-out feature, in order to break from the socket connect routine after a certain length of time if the connection is not established? I would appreciate if anyone can suggest a solution to this problem. Please email to the following address. Khalid Mirza. The Ohio State University mirza@magnus.acs.ohio-state.edu or mirza@kilimanjaro.eng.ohio-state.edu
karn@envy.bellcore.com (Phil R. Karn) (01/10/91)
I sent mail to Mirza explaining that there are no giveup timers in my TCP because I strongly believe they don't belong there - the application (or the user) should always make the decision when to give up. All you have to do in my code is to set up a timer that does an "alert" on the task - this should cause a connect() call to return -1. BTW, I realized that one reason people think they need timeouts in TCP is so they can try a series of IP addresses (e.g., the various addresses of a multi-homed host, or a series of MX sites for a piece of mail). I think I have a better approach that not only eliminates the need for TCP timeouts, but performs better when you have a long list of IP addresses to try and only one or two actually work. You simply give TCP the complete list when you initiate the connection. TCP sends a SYN to the first address and starts its (pre-initialized) retransmission timer. If the timer expires, TCP advances to the next address on the list and sends a SYN to that one. And so on. If it reaches the end of the list, it wraps back to the beginning, backs off its retransmission timer (note that backoff has NOT happened until this point) and repeats the whole process. The first SYN/ACK response will tell TCP which remote address to use for the connection; at this point the other IP addresses are discarded and the connection continues normally. Any additional SYN/ACK responses from the other addresses elicit RSTs, so they don't create any lingering half- open connections. I think this scheme is both simple and elegant. Comments? Can anyone suggest how a socket-oriented interface to such an enhanced connect call should look? Should I extend the connect() call or create an entirely new one? Phil
nelson@sun.soe.clarkson.edu (Russ Nelson) (01/10/91)
In article <1991Jan9.183444.14852@magnus.ircc.ohio-state.edu> mirza@magnus.ircc.ohio-state.edu (Khalid Mirza) writes:
I am using the KA9Q Internet Protocol Package at The Ohio State
University for developing an internet FAX facility for IBM PCs.
I have the following question about the software:
While trying to establish a TCP socket connection, the "connect"
routine does not time-out if the socket listener on the other end
is not running. Is there any way to include the time-out feature,
in order to break from the socket connect routine after a certain
length of time if the connection is not established?
Why would you want to? There are only two reasons I know of to cancel
a connection, once started:
1) If you run out of resources, and suspect that the resources tied up
by not-yet-established connections could be put to better use by
other potential connections,
2) If you decide to withdraw the connection. For example, you sent hate
mail to karn@ka9q.bellcore.com about his avoidance of timeouts, and
you became convinced that timeouts were indeed bad, then you would
want to cancel that piece of mail.
But really, neither of the above are real "timeouts", in the sense that
neither waits a fixed period of time before wimping out.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.