Re: 4.2/4.3 TCP and long RTTs

Greg Skinner (gds@EDDIE.MIT.EDU)
Fri, 12 Dec 86 00:07:53 EST

> 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

I haven't looked at 4.3 telnet or TCP to see if this is fixed or
handled differently.


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:00 GMT