Caldera Network Desktop 1.0/caldera-network-desktop-1.0.bin/doc/HOWTO/mini/LBX

Text File | 1995-10-29 | 14.1 KB | 356 lines

  The LBX Mini-HOWTO
  Paul D. Smith <[e-mail]>
  v1.01, 23 Oct 1995

  This document describes how to use Low-Bandwidth X (LBX): an
  extension to the X distribution which provides better service for
  running X applications over serial lines, wide-area networks, and
  other low-bandwidth, high-latency transports.


  1.  Introduction

  Low-Bandwidth X (LBX) attempts to recognize that in this day and age,
  not everyone will be a fast LAN hop or two away from the system that
  they are running their applications on.

  The X protocol can generate an extraordinary amount of traffic,
  especially for simple-seeming things such as creating new windows.  As
  anyone who has tried to use X over a dial-in modem at 14.4 or even
  28.8 can attest, creating new X windows can involve an excruciating
  wait.

  LBX is fundamentally a compression and caching scheme designed to
  minimize the amount of X traffic generated between two systems.


  2.  What's The Status Of LBX?

  Currently the X Consortium is distributing an LBX snapshot with the
  X11R6 distribution as a "Work In Progress".  That means that it
  probably has bugs, may not be extremely stable, and won't be
  compatible with the final version of LBX.

  Fortunately, there are *no* code changes needed to X clients to use
  LBX, so, unless you are trying to write applications which somehow
  explicitly interact with the LBX library, you don't have to worry
  about the fact that the interface will change.

  The instability of LBX is another matter; it is indeed not extremely
  solid.  You will have to judge for yourself whether the speed-up you
  gain by using it is worth the instability it introduces.

  Patches to LBX are being distributed with patches to X11R6, and
  nowhere else (that I'm aware of).  If you want to use LBX you should
  be sure to get the latest version of X11R6 (for Linux users that's
  currently XFree86 3.1.2).


  3.  Who Can Benefit From LBX?

  If you use a modem to dial into a service provider, then run X
  applications on remote machines with their DISPLAYs set to your local
  machine (or vice versa), LBX will speed up that connection.  Also if
  you set DISPLAYs from systems across WANs (other countries, for
  example) or other slow links, LBX can help.


  4.  Who Doesn't Need LBX?

  LBX is useless, of course, if you're only running applications
  locally, or if you're not running X at all :).

  Also, if you're running on a fast LAN LBX won't be much help.  Some
  people say "if LBX cuts down on network traffic, wouldn't it be good
  to use even on fast LANs?"  It might be, if your goal is to reduce
  network traffic.  But if your goal is to get better response time LBX
  probably isn't what you want.  Although it does introduce caching and
  compression, that comes at a cost on both ends (extra memory for
  caching, and extra CPU for decompression).  If your link is fairly
  speedy LBX will probably result in an overall slowdown.


  5.  How Does LBX Work?

  LBX works by introducing a "proxy server" at the client side, which
  performs caching and compression.  The X server knows that the client
  is using a proxy server, and decompresses accordingly.

  Here's a "normal" setup for remote X clients.  In our discussion,
  LOCAL is always the workstation sitting in front of you, whose monitor
  you're looking at, and REMOTE is the remote workstation, where the
  actual application is running.

       REMOTE                               LOCAL
   +-----+                                             +-----+
   | APP |-\          Network            +----------+  |     |\
   +-----+  \--------------------------->| X SERVER |=>|     ||
   +-----+  /       (X Protocol)         +----------+  +-----+\
   | APP |-/                                          /_____//
   +-----+


  When using LBX, a proxy server (lbxproxy) is introduced on the remote
  side, and the applications talk to that process instead of directly to
  the LOCAL server.  That process then performs the caching and
  compression of X requests and forwards them.  It looks like this:

       REMOTE                                         LOCAL
                                                                 +-----+
   +-----+  +-------+           Network            +----------+  |     |\
   | APP |->| PROXY |----------------------------->| X SERVER |=>|     ||
   +-----+  +-------+       (LBX/X Protocol)       +----------+  +-----+\
   +-----+   /                                                  /_____//
   | APP |--/
   +-----+

  Details on exactly what caching and compression LBX does is beyond the
  scope of this document (and probably would be quickly out-of-date
  anyway :).


  6.  What Do I Need To Use LBX?

  You need an X server on your LOCAL system which has the LBX extension
  compiled in.  For Linux systems, XFree86 3.1.2 servers do not come
  with LBX linked in.  You will need to get the XFree86 Link Kit from
  your friendly neighborhood XFree86 or Linux FTP site and relink your
  server (this is quick and easy and doesn't take up too much room,
  unlike rebuilding X from scratch).

  You can use the xdpyinfo command to see if your server has the LBX
  extension: run xdpyinfo and look at the list just under "number of
  extensions"; you should see LBX listed there.

  Next, you need to get an lbxproxy program compiled for the REMOTE
  system.  This is the tricky part.  There is unfortunately no "broken
  out" distribution of lbxproxy, so you will have to either (a) get and
  build most of the standard X11R6 and workInProgress hierarchies, or
  (b) find someplace to get a pre-compiled lbxproxy binary for your
  system.  The latter is much preferred of course :)

  The lbxproxy is a single executable.  There are no configuration
  files, resource files, etc. associated with it.


  7.  What Don't I Need To Use LBX?

  The REMOTE system *does not* need a new X server (as always, the
  REMOTE system doesn't even need *any* X server running).  Also, the
  application you want to run *does not* need to be linked with any
  special version of X11, or any special libraries; I regularly use
  commercial X11R5 apps over LBX with no trouble.

  You *do not* need root or other privileged access on the REMOTE
  system; the lbxproxy process runs under your normal access
  permissions.  Further, you can run it right from your home directory:
  it does not have to be installed anywhere.


  8.  How Do I Start LBX?

  OK, here it is... after all that it's actually quite simple.  Replace
  LOCAL and REMOTE below with the hostnames of your local workstation
  and remote system, respectively (don't get them mixed up! :)

  On LOCAL:

   1. Start your X server.

   2. Use "xhost +REMOTE" to give the remote system access to your X
      display, if necessary.

  On REMOTE:

   1. Start lbxproxy and tell it to forward to the LOCAL X server, like
      this:

        $ lbxproxy -display LOCAL:0 :1 &

      (this tells lbxproxy to use display :1; if you have >1 display
      already you can use :2 or whatever instead).  You also probably
      want to redirect stdout and stderr; depending on how your lbxproxy
      was compiled it might generate some debugging output.

   2. Set your DISPLAY environment variable to point to lbxproxy:

        $ DISPLAY=:1
        $ export DISPLAY

      Or, if you use csh or clones:

        % setenv DISPLAY :1

   3. Start your X applications!

  That's it; all X apps that are started up pointing to :1 will use LBX.
  Note in theory there's no reason you couldn't also start X apps
  pointing to LOCAL:0 and have both running at the same time, but in
  practice I've found LBX to be unstable in that configuration
  [[although testing on this was done with XFree86 3.1.1]].  All or
  nothing is safest.


  9.  Problems.

  Here're some common problems:

  Q1) I tried the above, but nothing happens/X server crashes/app
      crashes/lbxproxy crashes...

   A) There's a bug in LBX released with X11R6 p11 (XFree86 3.1.1) where
      lbxproxy must be one of the first 7 or 8 clients to attach to your
      X server, or LBX will corrupt memory in your server causing
      unpredictable results.

      The best way to avoid it is to get XFree86 3.1.2, where I think
      the problem is resolved.

      Another simple way to avoid it is ensure that you always start the
      lbxproxy on REMOTE before almost any other X apps are started on
      LOCAL.


  Q2) lbxproxy exits with a "access denied" error.

   A) Make sure you remembered to use "xhost +REMOTE" on the LOCAL
      system to give access permissions to REMOTE.

      Try running a normal X app like xclock and have it display on the
      local system:

        $ xclock -display LOCAL:0

      If that doesn't work, it's xhost or some other basic X problem,
      not LBX.  If that does work, try re-running lbxproxy with access
      permissions turned off:

        $ lbxproxy -display LOCAL:0 :1 -ac &


  Q3) LBX runs for a while, but my X server crashes/lbxproxy crashes/my
      apps exit abnormally (esp. with some apps)

   A) Yeah, well, LBX is a work-in-progress! :) :-/

      By this I don't mean that your apps will necessarily crash, but I
      have no doubt that your environment with LBX will be less stable
      then without it.  The more advanced your X apps are, the more
      likely they are to upset LBX.

      As I mentioned before, everyone will have to make his/her own
      judgment as to whether LBX is worth running at this early stage.
      If not, you have something to look forward to! :)


  10. LBX README

  Here I enclose some excerpts from the LBX README file, which is the
  only documentation on using LBX distributed with X11R6 up to p12.  I'm
  sure this is Copyright by the X Consortium; hopefully they won't mind
  me quoting it here.  This is mostly FYI, but might be interesting.

----- X11R6/xc/workInProgress/lbx/README --------------------------------------
$XConsortium: README,v 1.2 95/01/06 19:12:51 gildea Exp $

                Low Bandwidth X
                     (LBX)

This tree contains a snapshot of the code for Low Bandwidth X, the effort to
develop a standard for running X applications over serial lines, wide-area
networks, and other low-bandwidth, high-latency transports.  While many of
the major pieces of the eventual standard are represented here, LBX is *not*
done yet; this code should be treated as an "alpha" or "prototype" for people
who are interested in seeing the overall form that LBX is expected to take.

             ******************************************************
             *                                                    *
             *                      WARNING                       *
             *                                                    *
             *    This version of LBX is *NOT* a standard of      *
             *    the X Consortium and will *NOT* be compatible   *
             *    with the final version.                         *
             *                                                    *
             ******************************************************

The goal of LBX is to improve the startup time, performance, and interactive
feel of X applications run over low bandwidth transports.  LBX does this by
interposing a "pseudo-server" (called the "proxy") between the X clients and
the X server.  The proxy caches data flowing between the server and the
clients, merges the X protocol streams, and compresses the data that is sent
over the low bandwidth wire.  The X server at the other end uncompresses the
data and splits it back out into separate request streams.  The target is to
transparently make many X applications usable over 9600 baud modems.

This code snapshot contains the following features:

    o    LZW compression of the binary data stream.  Since commercial use
    of LZW requires licensing patented technology, we are also looking
    for an unencumbered algorithm and implementation to provide as well.

    o    Delta compression of X packets (representing packets as "diffs"
    against previously sent packets).

    o    Re-encoding of some graphics requests (points, lines, segments,
    rectangles, and arcs).

    o    Motion event throttling (to keep from flooding the wire).

    o    Caching of data in the proxy for large data objects that otherwise
    would be transmitted over the wire multiple times (e.g. properties,
    font metrics, keyboard mappings, connection startup data, etc.).

    o    Short-circuiting of requests for constant data (e.g. atoms,
    colorname/rgb mappings, and read-only color cells).

However, the following items have yet to be implemented (which is why it
isn't a standard yet...):

    o    Re-encoding of a number of requests (e.g. QueryFont), events, etc.

    o    Support for BIG-REQUESTS extension.

    o    A non-networked serial protocol for environments which cannot
    support os-level networking over serial lines.

    o    A full specification needs to be written describing the network
    protocol used between the proxy and the server.

The LBX team is continuing to work on both the implementation of the remaining
items and the full specification.  The goal is to have all of the pieces ready
for final review by the public later this year.  Since the specification for
LBX *will* change, vendors are discouraged from building products based on
this prototype.

However, everyone is strongly encouraged to work with the code, examine the
concepts, comments on alternatives, and volunteer to help finish it up!

                Dave Lemke <[e-mail]>
                Dale Tonogai <[e-mail]>
                Keith Packard <[e-mail]>
                Jim Fulton <[e-mail]>
                Chris Kanterjiev <[e-mail]>

 [...]

                     Usage

Start the X server as usual, and then start the proxy.  The lbxproxy
is a pseudo-server, so any clients that wish to use it need to adjust
their DISPLAY.  By default, the proxy will listen on hostname:1.
This can be changed by using the ':portnum' argument.

Example:

If the proxy is to be running on a host named "sharedhost", connecting
to an LBX-capable X server on a desktop machine named "mydesktop", you
could use the following command to start the proxy (which would be
known as display "sharedhost:7"):

    mydesktop%  rlogin sharedhost
    sharedhost%  lbxproxy -display mydesktop:0 :7 &
    sharedhost%  xclient -display sharedhost:7

 [...]
-------------------------------------------------------------------------------