Newsgroups: comp.protocols.tcp-ip.ibmpc Path: utzoo!utgpu!watserv1!watmath!att!bellcore!envy!karn From: karn@envy.bellcore.com (Phil R. Karn) Subject: Re: KA9Q question Message-ID: <1991Jan9.210126@envy.bellcore.com> Sender: usenet@bellcore.bellcore.com (Poster of News) Reply-To: karn@thumper.bellcore.com Organization: Packet Communications Research Group (Bellcore) References: <1991Jan9.183444.14852@magnus.ircc.ohio-state.edu> Date: Wed Jan 9 21:01:26 1991 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