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

| 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