casey@gauss.llnl.gov (Casey Leedom) (12/08/89)
I just finished a massive rewrite of my remote X11 standards proposal.
I got several requests for copies, so I'm going to post it here. Please
excuse the length.
Major changes are mostly in the area of providing more detail and
making the proposed protocol much more specific to X11.
-----
Thu Dec 7, 1989
``XRPCP''
X11 Window System
Server DIX/DDX interface
Remote Procedure Call Protocol
DRAFT
Standard Proposal
Abstract:
This is a proposal for a simple, bandwidth efficient Remote Procedure
Call Protocol, XRPCP, to implement the X11 Window System Server DIX/DDX
interface. This is the interface between the device independent and
device dependent code in the X11 server. This protocol would be used to
facilitate the splitting of the DIX and DDX sections of the X11 Server
into two cooperating processes.
The primary motivation for this protocol is to allow Workstations to
run X11 when they are remotely connected to Network Hosts via low
bandwidth links and/or the Workstations don't support the software
necessary to run X11. This would be accomplished by separating the
typical X11 Server which directly manages Workstation resources into
two parts: an X11 DIX Server, Xdix (or perhaps Xrpc?), and an X11 DDX
Server, DX``platform''. Xdix would contain the X11 Window System
Server/Client communications modules, high level graphics facilities,
and graphics database. An X11 DX Server would providing remote access
to the Workstation's resources (input handling, rasterization, etc.)
An example would be an IBM PC with VGA to a Network Host via an
EIA232 serial link. The personal computer would run, say, DXvga and
the Network Host would run Xdix.
XRPCP 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 TCP/IP network protocol suite in our examples for
much the same reason. Whenever possible we will try to pull back to
consider XRPCP from a more general perspective.
Rational:
Many of us who work with X11 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
EIA232. The situation cries out for a standard ... :-)
Language and Terms:
Workstation A Display, keyboard and some graphics input
device.
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.
X11 Server Traditional X11 Server containing Server/Client
communications modules, high level graphics
facilities, graphics database, and Workstation
resource management functions.
X11 DIX Server X11 Server whose Workstation resource
Xdix management code has been removed. It fulfills
it's input and output functions by working with an
X11 DDX Server via an XRPCP.
X11 DDX Server Workstation management code that runs on a
DX``platform'' Workstation. This code provides access to the
Ex: DXvga, DXmac Workstation's resources via an XRPCP. For purposes
DX* of brevity we'll often refer to X11
DDX server(s) in the abstract as ``DX*''.
Design:
It's impossible to consider the above outlined design without
addressing the alternatives. In particular:
Run the X11 Server on the Workstation and come up with a simple,
more efficient representation of the normal network protocols for
low bandwidth links.
For EIA232 links in particular, 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 information that isn't
necessary to this application. Certainly this would effectively
require that we implement higher level network protocol engines on the
Workstations. And which higher level protocols are we going to
support? TCP/IP? DECNET? Others? There's also the hassles
associated with set up, shut down, and routing of new network links.
But most importantly, putting the whole X11 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 X11 Server on the Network Host as an X11 DIX
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 XRPCP 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's my feeling that putting the most of the X11 Server on the
Network Host 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:
An X11 DDX Server is software that runs on a Workstation. The X11
DDX Server operates in one of two modes: Dumb Terminal or X11 DDX
Server. In Dumb Terminal mode, the X11 DDX Server simply passes key
strokes through a communications link and displays incoming characters
in some simple-minded fashion. In X11 DDX Server mode, the X11 DDX
Server provides various graphics facilities via an X11 DIX/DDX RPC
Protocol to an X11 DIX Server. Switching from one mode to the other is
instigated by the X11 DIX Server. There should be some method to reset
the X11 DDX Server to Dumb Terminal mode in the event of errors causing
the link to ``lock up''.
An X11 DIX Server is software that runs an a Network Host. It
provides the standard X11 Server facilities. It implements its X11
Server functionality via the facilities provided by an X11 DDX Server.
A typical scenario would have a user at home using a Workstation
(e.g. a Macintosh II, an IBM PC with a VGA, an X11 Terminal, or any
other hardware capable of running an X11 DDX Server). 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 an X11 DIX Server, specifying any
communication options. The X11 DIX Server would establish ownership of
X11 Window System resources (X11 Display number, etc.), and then
commence negotiation with the X11 DDX Server to establish an X11
DIX/DDX RPC Protocol connection and cause the X11 DDX Server to enter
into X11 DDX Server mode. X11 applications would then connect to the
X11 DIX Server in the same way that they would connect to any
traditional X11 Server. When the X11 DIX Server shut down, it would
cause the X11 DDX Server 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 XRPCP version negotiation
between X11 DIX and X11 DDX Servers. X11 DIX and X11 DDX Servers will
exchange supported protocol versions and agree on a mutually supported
version. If no version is supported by both, the X11 DIX Server will
exit with an error.
It may be necessary to specify a minimal set of versions that must be
implemented by all X11 DDX Servers and X11 DIX 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 X11 DIX Server via:
Xdix -XRPCP 5
The following diagram gives a description of the communications
arrangements over various media using ISO terminology:
7. APPLICATION: XRPCP
6. PRESENTATION: byte ordering, compression, security
1-5. communications:
point to point: EIA232, etc.:
5. SESSION: NONE
4. TRANSPORT: NONE
3. NETWORK: NONE
2. LINK: error detection/correction
1. PHYSICAL: RS232, etc.
multicast: TCP/IP over ethernet, etc.:
5. SESSION: TCP
4. TRANSPORT: TCP
3. NETWORK: IP
2. LINK: 802.3, etc.
1. PHYSICAL: ethernet, etc.
A PRESENTATION layer is noted in the above diagram that hasn't been
covered so far. Obviously any presentation layer services should be
negotiated between the X11 DIX and X11 DDX Servers (including of course
implementation version agreement as above for the XRPCP), but it's not
completely clear what should be in this layer. Certainly byte ordering,
but what about data compression and security features?
There's also the old ISO vs. non-ISO (typically TCP/IP) argument: why
divide one protocol into two protocols simply for layering purposes
when it introduces yet another protocol start up and shut down? In the
ISO world the APPLICATION and PRESENTATION layers above would almost
certainly be introduced as two orthogonal network protocols. In the
TCP/IP world they would probably be integrated into a single protocol.
Since my experience is predominately in the TCP/IP world and I am an
adherent to its principles, I prefer to think of the two layers as
simply two different functional sections of one inseparable protocol
all of whose start up, option and version negotiation, and shut down are
bundled in one network layer connection.
Practical Considerations:
The initial XRPCP and the negotiation mechanisms to start up and shut
down an XRPCP connection must be designed. Implementation of error
correction and security protocols can be deferred for later versions.
I propose simply using most significant byte first for byte ordering in
the first version. Later versions might use byte ordering agreement
negotiation.
A sample X11 DIX Server, Xdix, must be designed and implemented. At
least one X11 DDX Server must be designed and implemented. The first
X11 DDX Servers should probably be for one of the popular personal
computers like the Macintosh II or the IBM AT with VGA, DXmac and DXvga
respectively.
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.
Protocol design issues will be simplified by the fact that the
protocol is essentially going to be a direct implementation of the X11
DIX/DDX interface with a remote procedure call mechanism instead of the
more typical procedure call interface. This can be implemented using
standard RPC methods of stub procedure interfaces, etc.
The protocol design will be complicated be any data sharing that may
exist between the DIX and DDX sections of the X11 server. Such data
sharing will require additional facilities in the DDX RPC stub section
of the X11 DIX server to enable the X11 DDX Server to access the shared
data. (Yes, I'm proposing that any such shared data be kept in the X11
DIX Server since this will entail the fewest modifications to the
present X11 DIX code.) I'm not familiar with the X11 Server, so I
don't know how extensive data sharing such as this may be.
Implementation of a sample X11 DIX Server and X11 DDX Servers 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 probably be learned from
AT&T's Blit/Layers design also.) 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 X11 DIX and X11 DDX Servers for various platforms, just as
there is for more traditional servers. There will also still be
a market for terminals that implement X11 DDX Servers. 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 the X11 Window
System 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.
Casey