Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!sdcsvax!ucbvax!BU-CS.BU.EDU!bzs From: bzs@BU-CS.BU.EDU (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: SUPDUP protocol Message-ID: <8710061923.AA04589@bu-cs.BU.EDU> Date: Tue, 6-Oct-87 15:23:13 EDT Article-I.D.: bu-cs.8710061923.AA04589 Posted: Tue Oct 6 15:23:13 1987 Date-Received: Fri, 9-Oct-87 22:46:54 EDT References: <12340323701.42.PADLIPSKY@A.ISI.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 79 From: Michael Padlipsky >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