Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!lll-winken!lll-crg.llnl.gov!casey
From: casey@lll-crg.llnl.gov (Casey Leedom)
Newsgroups: comp.windows.x
Subject: DRAFT: Point-to-point X protocol proposal (long)
Keywords: DRAFT, protocol specification, proxy server, server engine
Message-ID: <26333@lll-winken.LLNL.GOV>
Date: 3 Jun 89 00:19:14 GMT
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@lll-crg.llnl.gov (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 215

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 ... :-)

Casey