casey@lll-crg.llnl.gov (Casey Leedom) (06/03/89)
Abstract:
This is a proposal for a simple, bandwidth efficient X Engine
Protocol over a point-to-point links.
[If one already exists, then this is a request for information
about it. I haven't seen anything about something along these
lines in nearly nine months of following comp.windows.x, so I
doubt that one does exist. I apologize in advance if this is a
mistaken assumption.]
This protocol would be used to implement X functionality in Client
Machines connected to a Network Host via a point-to-point link. An
example would be a Macintosh connected to a Vax via an RS232 serial
link. This protocol would be useful in these configurations when:
1. The Client Machines don't have support for the larger protocols
that X currently runs over [IP].
2. Where those larger protocols would be inappropriate or make
inefficient use of the point-to-point link (e.g Serial Line
Ineternet Protocol (SLIP) over a relatively slow RS232 line where
SLIP would use up a large portion of the link bandwidth).
3. Where setting up higher level protocol links, like SLIP, would
incur large effort and network routing problems.
Justification:
A lot of us who work with X on the job would really like to have the
same work environment at home when we ``dial in'' to work. Prohibiting
this are cost and performance considerations. Not many people or
institutions can afford to extend the company's ethernet out to
people's houses and install workstations there. Alternatively, using
a high speed leased line or modem, an ``X Terminal'', and running SLIP
across the link leads to intolerable performance.
[Currently, even with high speed dedicated lines, attempting to
run IP over these relatively slow (compared to ethernet 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. Where there's a desire to put a
personal computer of some kind and an X workstation environment on an
employee's desk, but the cost of the duplicated hardware, ethernet
installations, etc. is excessive.
Finally, even granting the ability to afford high performance or deal
with low performance solutions, the administrative nightmare of having
to maintain constantly changing network configurations is too much to
be considered by the faint of heart.
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 RS232 lines. The
situation crys out for a standard ... :-)
Technical Outline:
A Client Machine is a computer that may or may not be hooked up to any
network itself. There is a point-to-point link between the Client
Machine and a remote Network Host. The Network Host has network
facilities - even if only a loopback interface or a mechanism like UNIX
sockets.
A Server Engine is software that runs on a Client Machine. The Server
Engine operates in one of two modes: Dumb Terminal or X Engine. In
Dumb Terminal mode, the Server Engine simply passes key strokes through
the point-to-point link and displays incoming characters in some
simple-minded fashion. In X Engine mode, the Server Engine provides
various graphics facilities available via a simple, efficient X Engine
Protocol to a Proxy Server at the other end of the point-to-point link.
Switching from one mode to the other is instigated by a Proxy Server.
There should be some method to reset the Server engine to Dumb Terminal
mode in the event of errors causing the link to ``lock up''.
A Proxy Server is software that runs an a Network Host. It provides
the standard X server facilities via network communication protocols.
It implements its X functionality via the facilities provided by the
Server Engine.
A typical scenario would have a user at home using a Client Machine
(e.g. a Macintosh II, an IBM PC with a VGA, an X Engine Terminal, or
any other hardware capable of running a Server Engine). The user would
have a modem attached to the Client Machine and use that in Dumb
Terminal mode to dial up a remote Network Host, H. Once logged in to
the Network Host, the user would start up a Proxy Server, specifying any
communication options. The Proxy Server would establish ownership of
an X Display number, N, and then commence negotiation with the Server
Engine to establish an X Engine Protocol connection and cause the
Server Engine to enter into X Engine mode. X applications would then
connect to the Proxy Server H:N (or unix:N if running on H and using
UNIX domain sockets) in the same way that they would connect to any
traditional X server. When the Proxy Server shut down, it would cause
the Server Engine to re-enter Dumb Terminal mode.
The use of RS232 in examples should not be considered as a limitation
of possible point-to-point link medias. It merely provides real world
reference.
Protocol Technical Specification Requirements:
The following requirement are laid down in an effort to promote
flexibility of future protocol changes and operational environments.
Initial protocol start up must include X Engine Protocol version
negotiation between Client Machine Server Engine and Network Host Proxy
Server. Server Engine and Proxy Server will exchange supported X
Engine Protocol versions and agree on a mutually supported version. If
no version is supported by both, the Proxy Server will exit with an
error.
It may be necessary to specify a minimal set of versions that must be
implemented by all Server Engines and Proxy Servers, but I don't think
that this would be necessary or wise. Market presure, etc. would 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 any other
version of X protocols ...
In the case of multiple mutually supported X Engine 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
version. Therefore the highest mutually supported version should be
used by the Server Engine and the Proxy Server. Another possibility
might be that certain versions are simply tuned for various
point-to-point 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 the Proxy
Server via:
Xproxy -EngineProtocol 5
Initial protocol start up must include Error Correction Protocol
negotiation. This would include deciding whether to use error
correction over the point-to-point link and if so, which version to
use. This allows non-error-free links to be used. This 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 X Engine
Protocols are also present here. Examples of this 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 X
Engine Protocols are also present here. Examples of this might be:
Xproxy -SecurityProtocol [version]
Practical Considerations:
The initial X Engine Protocol and the negotiation mechanisms to start
up and shut down an X Engine connection must be designed.
Implementation of error correction and security protocols can be
deferred. A sample Proxy Server, Xproxy, must be designed and
implemented. At least one Server Engine must be designed and
implemented. The first Server Engines should probably be for one of
the popular personal computers like the Macintosh II or the IBM AT with
VGA.
The design of the protocol 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 Server and Server Engines 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 is Graphon.) 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 Server Engines and Proxy Servers for various platforms, just
as there is for more traditional servers. There will also still
be a market for X Terminals that implement Server Engines. 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 X over
point-to-point links. I believe that such a standard would benefit the
X 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 hase to come
up with some cutesy name for the protocol. Preferably this should be
some outlandish acronym from an improbable set of words ... :-)
CaseyJONESD@kcgl1.eng.ohio-state.edu (David Jones) (06/03/89)
My understanding of X is that it does not proscribe support for any transport protocol that provides a reliable byte stream service. I think it would neat if LAT were a supported transport protocol, then an X terminal could easily present itself to a host as both an X server and a dumb terminal. I think terminal emulators run locally would outperform emulators running as clients on a remote host. David L. Jones | Phone: (614) 292-6929 Ohio State Unviversity | Internet: 1971 Neil Ave. Rm. 406 | jonesd@kcgl1.eng.ohio-state.edu Columbus, OH 43210 | jones-d@eng.ohio-state.edu Disclaimer: A repudiation of a claim.
casey@lll-crg.llnl.gov (Casey Leedom) (06/04/89)
| From: Ken Yap <ken@cs.rochester.edu> | | Do you cater for multiple connections in your point-to-point protocol? There isn't any need. The connection between the Proxy Server on the Network Host and the Server Engine on the Client Machine (probably a bad choice of terms there - maybe I'll start calling it the Frame Buffer) is just to enable the Proxy Server to use the screen, mouse, and keyboard of the Client Machine effectively. | Why not just replace the TCP/IP layer with something more byte | efficient? After all, all X needs is an error free byte stream. Design: Two possible designs come to mind: 1. X server runs on Client Machine and we come up with a simple, more efficient representation of the normal network protocols used to talk to X servers. 2. X server runs on Network Host as a Proxy Server for the Client Machine and we come up with a simple, efficient graphics protocol to enable the server to use the facilities of the Client Machine. 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 Client Machines. 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 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 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 Server just for a protocol translation. But most importantly, putting the whole server on the Client Machine 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 Client Machines we're interested in supporting won't have much memory. Assuming local disk leaves too many Client Machines 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 the most of the X server on the Network Host as a Proxy Server takes advantage of the Network Host's memory and native operating system network and 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 X Engine Protocol and possibly something like save-unders. 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 Server Engine and the Proxy Server. This involves careful consideration and balancing of the loads on the Network Host, Client Machine, and the link. It's my opinion/feeling that putting the X Server on the Network Host as a Proxy 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 Client Machines that we want to support. Casey
casey@lll-crg.llnl.gov (Casey Leedom) (06/04/89)
| From: Peter Scott <PJS@grouch.JPL.NASA.GOV> | | I have a suggestion, that it be implemented using a command cache. Since | the problem is bandwidth (1200bd compared to ~T1), have the X server | group sets of protocol requests that look as though they might be | repeated (e.g., primitives that make up the frame for a text window), and | with each set, send over to the engine a message that it is naming that | set of commands macro n. The engine puts that set of commands on the top | of a stack, and whenever the server would send that same group of | commands, it sends instead the somewhat shorter command, "do macro n". | This causes the engine to execute the commands it has stored, and put | them back on top of the stack. When it runs out of space it takes the | bottom macro off the stack, and sends a message to the server saying, | "macro n forgotten". If you can make the server intelligent enough to | recognize reasonable command groupings then this can save oodles of time. This sounds like an excellent suggestion, but I don't know enough about the X protocol and traditional server design to know whether the problem of recognizing ``groups of protocol requests that look like they're going to be repeated'' is a doable task. Certainly such a design feature in the X Engine Protocol would address the endlessly debated RISC/CISC question quite nicely. We could only provide those graphics primitives in the X Engine Protocol that were known to be used frequently. These would probably form a fairly small, simple RISC-like set. Then your macro idea would effectively give us a dynamic micro-code extension capability. Casey
mongo@helios (Mongo Package) (06/04/89)
In <26333@lll-winken.LLNL.GOV> casey@lll-crg.llnl.gov (Casey Leedom) wrote: [A lot of ideas on how to set up a "Proxy Server" on a "Big" machine sending a simplified serial protocol to a "Little" machine.] This sounds extremely similar to what GraphOn corporation is already selling with their OptimaX 2000 terminals. The "proxy" server runs on a Sun or VAX and talks to their terminal. The terminal has enough local smarts to do vector and raster drawing, including bit blits, but that's about all. Steve Allen mongo@helios.ucsc.edu mongo@portal.bitnet ...ucbvax!ucscc!helios!mongo