Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!UC.MSC.UMN.EDU!slevy
From: slevy@UC.MSC.UMN.EDU ("Stuart Levy")
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TCP/IP terminalservers and BREAK(/^C)
Message-ID: <8810310036.AA12564@uc.msc.umn.edu>
Date: 30 Oct 88 23:36:46 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35

Michael Patton <map@gaak.lcs.mit.edu> writes...
> Except that the client end can't possibly have enough information
> about what is and isn't going to cause output to be flushed, only the
> server end (and maybe the user if they know the insides of the server)
> can know that.  You can't expect a user to type magic commands
> frequently so for this scheme to work you need to add new options in
> TELNET to allow the server to tell you every time this changes.

I surely agree with this...

> These will have the same implementation problem that GA had (see parallel
> discussion) where the server process can't get at the information.

But not with this.  Yes, with many present implementations a telnet server
can't get the necessary information from the user process or terminal driver
or whatever.  But once there's a mechanism for using the information,
mechanisms will be developed (operating systems will be modified) to make it
available where necessary.  Cray and Encore at least, and probably others,
have already done this in different ways.  4.3BSD "almost" does it (by providing
a way to switch off the terminal driver in a pseudo-tty, but don't think they
have any way to notify the server of application-initiated changes;
I haven't seen 4.3-tahoe though).

> All in all, I think this suggestion only makes the problem harder to
> solve right.  Given the underlying TCP functionality, I think the
> original Abort Output (AO) is the best we're going to do, except for
> the problem of implementing it in some cases.

Aw, give it a chance!  This is a classic chicken vs. egg problem, might as
well allow a few species of birds to evolve before predicting we'll never
taste an omelet.  Though I'll agree to the extent that we need to leave
room in our diet for those reptilian operating systems that lack paths
for the necessary information... but that's what negotiations are about.

	Stuart Levy, Minnesota Supercomputer Center
	slevy@uc.msc.umn.edu