SUPDUP protocol


Barry Shein (bzs@bu-cs.bu.edu)
Tue, 6 Oct 87 15:23:13 EDT


From: Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
>Speaking of misunderstandings, please be aware that I'm NOT one of
>SUPDUP's advocates. Just trying to "call for the order of the day" by
>asking for an explanation (which I'd still appreciate getting) of how
>windowing sorts of things minimize number of transmissions.

Although at this point I would love to see the core window gnurds jump
in perhaps I could offer some examples.

In the first place, window systems (the hardware used to support them)
present new transmission opportunities and a need for solutions. A
straightforward example from X is the ability either to track the
pixel-by-pixel motion of a mouse versus requesting the remote server
to simply inform the client (with a single transmitted event) when
certain conditions occur such as the mouse entering or leaving a
window. The rest of the tracking is done in the server.

[For those less grounded in such things let me point out that the
"server" is typically one large program in charge of the physical
screen, keyboard, mouse etc and the "clients" are the applications
programs which send requests to either the remote or local server.]

Similarly, keystrokes can be mapped into multiple character
transmissions on the server (by request of the client) and these
would typically be sent as one network transaction.

NeWS of course offers a whole other dimensionality in its ability to
send a program text (in postscript) to be executed locally by the
server's language interpreter. Such a text I assume could open a
window, display a form to be filled out, collect the user's entry and
zap it all back in one transmission.

[Let me stop right here and say I don't claim that any of these
features I describe are unique or even original with the systems I
mention, I am simply trying to stick to some examples I am familiar with.]

Thus modern, networked window systems (both of these use Internet
protocols for their transmissions) offer both more powerful problems
and more powerful solution models than previous protocols aimed
at keyboard/screen interactions.

>...If, however,
>your point is that the need for progress outweighs the need to avoid
>being charged for each character typed, so that windowing protocols
>should become the focus of the discussion irrespective of their
>properties in the cost dimension, I'm inclined to duly note it and
>repeat my question to everybody else as to whether a genuinely
>simple fix to RCTE (whether the protocol or the implementations)
>wouldn't be worthwhile, in context.

I think we can have both, all three; a fix to RCTE where it exists
currently (I don't have a version on the entire B.U. campus), progress
into the discussion of networked window systems, and cost reductions in
network transmissions under window systems -if these needs are expressed-!

That's the key point, I don't think such needs have ever been much
expressed, most of the window systems were developed within ethernet
environments where things like character-at-a-time overheads were
probably not very important.

The prospect (as people on this campus are asking for) of remote
access to facilities such as super-computers over long-haul networks
via windowed interfaces makes these issues more pressing. Data
visualization and this split interaction makes a lot of sense on
remote, high-end facilities with a graphically oriented workstation on
one's desk and a network connection.

I would dare to say that the transmissions we are already starting to
see generated by such interactions will make character-at-a-time
overhead seem like mere child's play. We're looking at the prospect of
a keystroke being echoed with a megabit or more of graphical data etc.

I suppose I could better allegorize my view as SUPDUP presenting a
finger in the dyke and others having run off to fetch some caulking to
put around the finger...it's a fine finger and the others will no
doubt come back with fine caulking.

        -Barry Shein, Boston University



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