Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!EDDIE.MIT.EDU!gds From: gds@EDDIE.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: 4.2/4.3 TCP and long RTTs Message-ID: <8612120507.AA06682@EDDIE.MIT.EDU> Date: Fri, 12-Dec-86 00:07:53 EST Article-I.D.: EDDIE.8612120507.AA06682 Posted: Fri Dec 12 00:07:53 1986 Date-Received: Mon, 15-Dec-86 00:36:06 EST References: <8612090834.AA13766@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa > Mike, > How can the TCP "just" inform the application about the problem? > Unless there's a control channel to the application that allows > the passage of status data, a send call must return an error. > After that error, the application can't tell how much of the data, > if any, was transmitted. "Reliable byte stream with possible gaps > in case of error" isn't very satisfying. > > Informing the application that the networking system is having trouble > getting acknowledgements does not mean that the networking system has > given up on sending that data. My intent was to point out that such a > decision should be left up to the application, which may in turn defer > the decision to the user. This was one of the qualities of the BBN > TCP/IP software, as you know. It is one of the reasons Bob Gilligan used > the BBN software for his demos. > There are some Unix applications, like the 4.2 version of telnet, which do a close() if they get something like ETIMEDOUT, which can occur if a TCP timer has gone off. In the 4.2 BBN TCP/IP, the timer going off does not cause the connection to be closed. Instead, a routine called advise_user lets the higher layers know about the problem and lets them deal with it. I was rather surprised to see that 4.2 telnet was giving up when the actual connection was not remotely closed. With a quick patch to telnet to prevent it from closing for errors when a TCP timer has gone off, you can maintain telnet connections for hours. The reconstitution protocols required that connections remain open for long periods of time during network dynamics. I haven't looked at 4.3 telnet or TCP to see if this is fixed or handled differently. --gregbo