Re: supdup protocol


JQ Johnson (jqj@drizzle.uoregon.edu)
Fri, 9 Oct 87 20:57:27 PDT


An important point about the evolution from telnet-style protocols to
X-style windowing protocols is that a parallel evolution is towards
remote file systems (e.g., though not i.e., SUN NFS). The pair of
trends implies that there are now many interesting alternatives available
for standardized distributed computing. Some examples:
1/ an interface to a remote command language interpreter that is
extremely smart about local editing (e.g. SUN cmdtool or the various
menu-based command extensions). The menu-based extension amount to PFCs,
but with a better user interface. They allow the transmission of a whole
command or part of it in a single packet rather than c-a-a-t (at the user's
typing rate).
2/ special purpose RPCs for typical commands, often with arguments that
are built automatically by the software on the local workstation. I never
run sysline style programs remotely over a telnet stream!
3/ transparent local editing. At least in some cases, it makes much more
sense to download a whole file and edit it locally. That was a user-interface
nightmare when downloading meant firing up FTP (but that's the way Symbolics
tcp/ip implements it). A remote file system gives you much more flexibility
and syntactic sugar. Note that if your charges are per-packet with a max.
packet size of 128 bytes, and you plan to type 1K keystrokes during the
editing of a single file, then even if the file is 127K bytes long it is
cheaper to download it! And of course an intelligent system design allows
downloading of only the pieces of the file actually needed.

Granted such things don't work well if your network connection is 9600b.
They work reasonably at 56Kb, though, given careful tuning. And they
are often a big win not just in terms of packet charges but in terms of
latency -- I'd much rather wait 5 more seconds for my (local) editor to
fire up on a remote file than wait 1 sec. for the echo of every keystroke!

 .
QUIT



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