casey@lll-crg.llnl.gov (Casey Leedom) (06/10/89)
| From: lupine!ed@uunet.UU.NET (Ed Basart) | Date: Wed, 7 Jun 89 08:24:30 PDT | | Ed Basart, NCD, Inc. | (415)694-0650 | ed@ncd.com | | We here at NCD are quite interested in the problem of running X over a | dial-up modem. However our point of departure is that the server runs in | the X terminal. The reason for this is adherence to the X architecture - | separate the problem at the client/server boundary. It also makes good | sense. X running on a Sun 3/50 pretty much consumes the entire processor | when drawing to the screen. Trying to run multiple at-home X servers on | the host will create performance problems and herky-jerky response. This | can be demonstrated by loading a few X servers on a diskful Sun, and then | try pounding away. Unfortunately I can't agree with you. And several people who've run the Graphon Optimax 200 say that the Proxy Window Servers don't seem to wipe out the host that badly. You've got to remember where a lot of those CPU cycles are burned in an X11 server: in the low level graphics code. The design I'm proposing still has that code on the Workstation. And I think the problems with server memory are abundantly clear. I think that it's going to be far more cost effective to use already in place equipment like personal computers to run window systems on. And for many of those systems, putting a full X11 Window Server on them with a full TCP/IP SLIP networking system is just more work than you want to think about. For those who don't have and don't want a personal computer, then there's something like an X terminal. I see my proposal as setting up the possibility of extremely cheap, cost effective, medium performance Workstations that a company like yours could manufacture. It's quite possible that the cost could get as low as $500. | Regardless, we already have a product that runs the server only the | the terminal (we prefer to call it a station), and now are writing | the software to support our station across a dial-up line. Our | experiments have shown SLIP to be OK at 38.4 Kbits, tolerable at | 19.2 Kbits, and unacceptable at 9.6Kbits. Our initial objective | is rather modest: a 4 to 1 improvement over SLIP. Merely removing | the TCP headers may be enough. We are now doing an implementation | of an X serial protocol server (daemon) and client on the Sun to | try our ideas out. | | If we get the X serial protocol to work, we'll gladly push it as | a standard. We have been waiting around for "someone else" to | do it, and will give it a go ourselves. You probably could get some form of compressed X protocol to work and be fairly bandwidth efficient, but then you'd be limiting yourself to X. ``What?'' you're saying, ``limiting myself to X???'' And I'd have to answer that my first proposal did the same thing, but a kind soul pointed out the errors of my ways. I'll send a copy of my current proposal in a follow up. It should also be pointed out that this will require a Proxy Server for the protocol conversion, but I also cover this in my proposal ... Casey
casey@lll-crg.llnl.gov (Casey Leedom) (06/10/89)
Fri Jun 9, 1989
Workstation Protocol
DRAFT
Standard Proposal
Abstract:
This is a proposal for a simple, bandwidth efficient Workstation
Protocol. This protocol would be used facilitate use of a Workstation's
resources (e.g. frame buffer, keyboard, mouse, etc.).
The primary motivation for this protocol is to allow Workstations to
use Windowing Systems when Workstations are remotely connected to
Network Hosts via low bandwidth links, and/or Workstations don't
support the software necessary to run a Networking Window System. This
would be accomplished by separating the traditional Window Server which
directly manages Workstation resources into two parts: a Proxy Window
Server and a Workstation Agent. The Proxy Window Server would contain
the Window System Server/Client communications modules, high level
graphics facilities, and graphics database. The Workstation Agent
would manage the Workstation resources.
An example would be a Personal Computer connected to a Network Host
via an RS232 serial link. The Personal Computer would run a
Workstation Agent and the Network Host would run a Proxy Window Server.
This Workstation Protocol would of course not be limited to this
application since it would provide general purpose access to a
Workstation's facilities. However, this document focuses almost
exclusively on this application in order maintain a concrete focus on
our primary goal. Additionally, we will often use the X11 Window
System and the TCP/IP network protocol suite in or examples for much
the same reason. Whenever possible we will try to pull back to
consider the Workstation Protocol from a more general perspective.
Rational:
Many of us who work with Window Systems on the job would like to have
the same work environment at home when we ``dial in''. Prohibiting
this are cost and performance considerations. Not many people or
institutions can afford to extend the company's network out to people's
homes and install workstations there. Alternatively, using high speed
leased lines or modems and running high level encapsulated high level
network protocols across the link leads to intolerable performance.
[For example: currently, even with high speed dedicated lines,
attempting to run IP over these relatively slow (compared to LAN
speed) lines wastes much of the available bandwidth with IP
overhead. Proposed SLIP protocol changes like header compression
will help, but reports indicate that interactive use is still no
fun. And, it should also be pointed out, high speed leased lines
cost ...]
Additionally, it would be nice to be able to take advantage of already
existing equipment like personal computers for this task.
There are also situations at many institutions which duplicate these
cost/performance issues on site. For instance, where there's a desire
to put a personal computer of some kind and access to a network Window
System environment on an employee's desk, but the cost of the network
installations, duplicated hardware, etc. is excessive.
The goal therefore is to come up with a cost effective solution that
let's personal computers be used, where desired, and runs with
reasonable performance over low to high speed communications links like
RS232. The situation cries out for a standard ... :-)
Language and Terms:
Workstation Minimally a Frame Buffer and Display, but also
frequently input devices like keyboard and mouse
or track ball.
Network Host Computer system with facilities for interprocess
communication.
Communications Link For our purposes, any media and link layer
protocols connecting a Workstation and Network
Host.
Window Server Traditional Window Server containing
Server/Client communications modules, high level
graphics facilities, graphics database, and
Workstation resource management functions.
Proxy Window Server Window Server whose Workstation resource
management code has been removed. It fulfills
it's input and output functions by working with a
Workstation Agent via a Workstation Protocol.
Workstation Agent Workstation management code that runs on a
Workstation. This code provides access to the
Workstation's resources via a Workstation
Protocol.
Design:
Two possible designs come to mind:
1. Window Server runs on Workstation and we come up with a simple,
more efficient representation of the normal network protocols
used to talk to servers.
2. Proxy Window Server runs on Network Host and we come up with a
simple, efficient graphics protocol to enable the server to use
the facilities of the Workstation via a Workstation Agent.
Even if we could come up with a more efficient representation of
normal network protocols, it would still have to carry multiplexing and
possibly other header information. A simple graphics primitive
protocol would also have to carry control information, so it's
debatable as to which could be implemented more efficiently with
respect to link bandwidth. Certainly this would effectively require
that we implement higher level network protocol engines on the
Workstations. The design of such a protocol translation and engine
suite would probably be harder than that of a graphics primitive
protocol. And which higher level protocols are we going to support?
TCP/IP? DECNET? Others?
We would also still need a Proxy Window Server just to handle the
protocol translations (unless of course we decide to modify the Network
Host's operating system network support). Having to keep at least a
stub Proxy Window Server isn't actually a bug. It let's us take
advantage of the Network Host's network and avoid the hassles
associated with set up, shut down, and routing of new network links.
But now we're context switching into and out of the Proxy Window Server
just for a protocol translation.
But most importantly, putting the whole Window Server on the
Workstation would lead to problems with server memory allocation. The
server would either end up with a fixed amount of local memory to live
in, have to assume local disk to page off of, or support remote paging
across the link. Living in a fixed amount of memory is a pain - when
the server runs out of memory, it has to start balancing its resource
usage (usually manually unless we want to get into the can of worms
presented by resource sharing algorithms). And it should be remembered
that many of the Workstations we're interested in supporting won't have
much memory. Assuming local disk leaves too many Workstations out in
the cold and requires writing paging software. Paging across the link
uses up link bandwidth and also requires writing paging software (this
time on both ends of the link).
Putting most of the Window Server on the Network Host as a Proxy
Window Server takes advantage of the Network Host's native operating
system memory management (virtual memory, paging, swapping, etc.).
This effectively amounts to paging across the link since redrawing any
graphics object requires that information be resent from the Network
Host. Some of this load should be alleviated by proper design of an
efficient Window Protocol and possibly something like X11 save-unders.
This also makes effective use of the Network Host's networking
facilities and avoids most of the hassles associated with trying to
manage dynamic network configurations.
On the down side, this will probably lead to higher load on the
Network Host both in terms of memory and CPU usage. It also isn't
clear what the division of labor with regard to graphics work should be
between the Workstation Agent and the Proxy Window Server. This
involves careful consideration and balancing of the loads on the
Network Host, Workstation, and link.
It's my feeling that putting the most of the Window Server on the
Network Host as a Proxy Window Server is the right approach. I believe
that the extra load on the Network Host is justifiable since it's
likely to have more memory and CPU resources than many of the
Workstations that we want to support.
Technical Outline:
A Workstation Agent is software that runs on a Workstation. The
Workstation Agent operates in one of two modes: Dumb Terminal or
Workstation Engine. In Dumb Terminal mode, the Workstation Agent simply
passes key strokes through a communications link and displays incoming
characters in some simple-minded fashion. In Workstation Engine mode,
the Workstation Agent provides various graphics facilities via a
simple, efficient Workstation Protocol to a Proxy Window Server.
Switching from one mode to the other is instigated by the Proxy Window
Server. There should be some method to reset the Workstation Agent to
Dumb Terminal mode in the event of errors causing the link to ``lock
up''.
A Proxy Window Server is software that runs an a Network Host. It
provides the standard Window Server facilities. It implements its
Window Server functionality via the facilities provided by the
Workstation Agent.
A typical scenario would have a user at home using a Workstation
(e.g. a Macintosh II, an IBM PC with a VGA, an X Terminal, or any other
hardware capable of running a Workstation Agent). The user would have
a modem attached to the Workstation and use that in Dumb Terminal mode
to dial up a remote Network Host. Once logged in to the Network Host,
the user would start up a Proxy Window Server, specifying any
communication options. The Proxy Window Server would establish
ownership of Window System resources (X Display number, etc.), and then
commence negotiation with the Workstation Agent to establish a
Workstation Protocol connection and cause the Workstation Agent to
enter into Workstation Engine mode. Window System applications would
then connect to the Proxy Window Server in the same way that they would
connect to any traditional Window Server. When the Proxy Window Server
shut down, it would cause the Workstation Agent to re-enter Dumb
Terminal mode.
Protocol Technical Specification Requirements:
The following requirements are laid down in an effort to promote
flexibility of future protocol changes and operating environments.
Initial protocol start up must include Workstation Protocol version
negotiation between Workstation Agent and Proxy Window Server.
Workstation Agent and Proxy Window Server will exchange supported
protocol versions and agree on a mutually supported version. If no
version is supported by both, the Proxy Window Server will exit with an
error.
It may be necessary to specify a minimal set of versions that must be
implemented by all Workstation Agents and Proxy Window Servers, but I
don't think that this would be necessary or wise. Market presure
should cause implementors to make most popular versions available
without the need to institutionalize the dreaded disease of backwards
compatibility. As an example, we don't require current X11 servers to
support older versions of X protocols ...
In the case of multiple mutually supported protocols, a decision must
be made as to which to use. This draft does not address that issue
beyond mentioning some possibilities. It might be presumed that a
higher version number would indicate an improvement over earlier
versions. Therefore the highest mutually supported version should be
used. Another possibility might be that certain versions are simply
tuned for various communications media. If that is the case, there
should probably be a mechanism to select a particular version over
other mutually supported versions. An example of such a biasing might
be starting up an X Proxy Window Server via:
Xproxy -WorkstationProtocol 5
Initial protocol start up must include Error Correction Protocol
negotiation. This would include deciding whether to use error
correction over the communications link and if so, which version to
use. This allows non-error-free links to be used which includes much
of the equipment already in place at many institutions. [Remember, it's
part of our stated goal to support in place equipment whenever
feasible.]
Many of the issues regarding multiple mutually supported Workstation
Protocols are also present here. X Proxy Window Server examples
might be:
Xproxy -CorrectionProtocol [version]
Initial protocol start up must include Security Protocol
negotiation. This would include deciding whether to use security
mechanisms and if so, which version to use. I don't envision using
this myself, but it's an obvious idea whose implementation and use
should be provided for.
Again, many of the issues regarding multiple mutually supported
Workstation Protocols are also present here. X Proxy Window Server
examples of this might be:
Xproxy -SecurityProtocol [version]
Practical Considerations:
The initial Workstation Protocol and the negotiation mechanisms to
start up and shut down an Workstation Protocol connection must be
designed. Implementation of error correction and security protocols
can be deferred. A sample Proxy Window Server (X11 Xproxy) must be
designed and implemented. At least one Workstation Agent must be
designed and implemented. The first Workstation Agents should probably
be for one of the popular personal computers like the Macintosh II or
the IBM AT with VGA.
The design of the protocols and negotiation mechanisms will require
input from various experts and concerned parties, coordination of draft
proposals, and reviews of those drafts. Implementation of a sample
Proxy Window Server and Workstation Agents will require donations of
time from various individuals for coding and testing, and coordination
of those efforts.
One possibility is to seek donations of already existing protocols
and code as a starting point. (A candidate that comes immediately to
mind for X11 is Graphon. Something could also probably be learned from
AT&T's Blit/Layers design.) This would require convincing such
companies that it is in their best interest to do this. Possible
arguments are:
1. This standards effort will go on whether they participate or not.
It's in their best interest to have input on the process, possibly
including large scale adoption of their protocols.
2. There will still be a market for high performance implementations
of Workstation Agents and Proxy Window Servers for various
platforms, just as there is for more traditional servers. There
will also still be a market for terminals that implement
Workstation Agents. One could argue in fact that the market will
be larger because of standardization.
Summary:
I believe that it is both possible and desirable to design a standard
for cost effective and reasonable performance support of Window Systems
over low bandwidth communications links. I believe that such a
standard would benefit the user community and open a business market
that is only now getting started.
If no one else more capable is willing, I volunteer to coordinate the
design and implementation of this protocol, and whatever coding and
testing I am capable of.
And, oh yes, one final practical consideration. Someone has to come
up with some cutesy name for the protocol. Preferably this should be
some outlandish acronym from an improbable set of words ... :-)
Caseycasey@gauss.llnl.gov (Casey Leedom) (06/11/89)
By the way, I forgot to thank Ed Basart of Network Computing Devices (ed@ncd.com) for his kind and generous offer to participate in this standards effort. I hope that our technical differences of opinion won't discourage him. Thanks again Ed! | From: lupine!ed@uunet.UU.NET (Ed Basart) | Date: Wed, 7 Jun 89 08:24:30 PDT | | If we get the X serial protocol to work, we'll gladly push it as | a standard. We have been waiting around for "someone else" to | do it, and will give it a go ourselves. | | Ed Basart, NCD, Inc. | (415)694-0650 | ed@ncd.com And, I guess it's time to move this subject off of xpert and onto xserial@expo.lcs.mit.edu if MIT wants to manage the list. If not, I'll gladly manage it off of lll-crg.llnl.gov. Casey