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> <NELSON.91Jan9153502@sun.soe.clarkson.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

