John Wroclawski (JTW@XX.LCS.MIT.EDU)
Wed 30 Sep 87 01:27:51-EDT

Hmm. The basic SUPDUP protocol doesn't address the remote echoing
overhead problem at all, and won't do a thing for those paying
per-packet charges, which is how this all started.

Some (long) time ago Richard Stallman designed and implemented an
extension called the SUPDUP Local Editing Protocol, which allowed a
remote display-oriented program, such as EMACS, to arrange to have
most operations performed at the user's local terminal, with
information transferred to the remote end as required. This vastly
reduces the need to send screen update information over the net, and
allows bunching of update information into a few large packets rather
than zillions of one-character ones. Network utilization is improved
in both directions.

This protocol was documented in at least one MIT AI Lab memo. I think
the final version of the AI memo that described SUPDUP included it

SUPDUP LEP is to some extend a superset of the functionality of RCTE,
and could be useful for reducing the load caused by
non-display-oriented programs.

The basic SUPDUP protocol has some very good ideas about how to do
virtual terminals, but could use some updating. A new protocol could
be based on the structure of SUPDUP, maintaining the LEP and input
processing concepts, but with a newer set of capability descriptors in
the startup negotiation and output encodings based on the ANSI X3.64
terminal standards. This protocol would nicely address both the
network efficiency concerns raised here and the problems which come up
using arbitrary window-based emulators as remote terminals.

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