THE LBX MINI-HOWTO

THE LBX MINI-HOWTO

Paul D. Smith <[email protected]>
v1.02, 17 Jul 1997

_________________________________________________________________

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 28.8 or even
higher 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.

What's The Status Of LBX?

As of the X Consortium's release of X11R6.3 in December, 1996, LBX is
a full extension to the X protocol. For XFree86 folks, that's XFree86
version 3.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.

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.

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.

What Do I Need To Use LBX?

You need an X server on your LOCAL system which has the LBX extension
compiled in. Unless you explicitly told it not to when building it,
X11R6.3 servers automatically enable LBX. Also, all XFree86 3.3
servers have LBX enabled by default.

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. If the remote system is not the same
type as your local system, the lbxproxy on your local system will do
you no good, of course.

There is unfortunately no "broken out" distribution of lbxproxy, so
you will have to either (a) get and build most, if not all, of X11R6.3
for the remote system, or (b) find someplace to get a pre-compiled
lbxproxy binary for your system. The latter is much simpler of course.

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

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 need _any_ X server running).

The application you want to run _does not_ need to be linked with any
special version of X, 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.

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. If you use xauth you may need to do more
than this; see the _xauth(1)_ man page for more information.

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 on the REMOTE system; if
that system has >1 display already you can use :2 or whatever
instead.

2. Set your DISPLAY environment variable to point to the display that
lbxproxy is providing, instead of the normal display:

$ 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.
Of course, there's no reason you couldn't also start X apps pointing
to LOCAL:0 and have both running at the same time.

Problems

Here are some common problems: Q) lbxproxy exits with an "access
denied" error. A) Make sure you remembered to use xhost +REMOTE on the
LOCAL system to give access permissions to REMOTE. Also, remember that
if you're using xauth you'll need to do other stuff.

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

$ xclock -display LOCAL:0

If that doesn't work, it's xhost or some other basic X problem, not
LBX.

Documentation

The only documentation available in a standard X distribution may be
the _lbxproxy(1)_ man page.

If you have access to the X source tree, then very interesting
information on LBX is available there: FileFormat
xc/doc/specs/Xext/lbx.mifFramemaker MIF
xc/doc/hardcopy/Xext/lbx.PS.Z(Compressed) Postscript
xc/doc/hardcopy/Xext/lbxTOC.htmlHTML

More detailed discussion of specific LBX algorithms is available here:
FileFormat xc/doc/specs/Xext/lbxalg.mifFramemaker MIF
xc/doc/specs/Xext/lbxalg.PS.Z(Compressed) Postscript

If you don't have access to the X11 source, you can obtain these files
from ftp://ftp.x.org/pub/R6.3/xc/doc/....

Alternatives

If you don't like lbxproxy for some reason: you're not satisfied with
the performance, it doesn't work for you, you don't want to hassle
with creating an lbxproxy for the remote host, or you simply are
interested in trying other options, there is at least one other
package for X protocol compression (anyone have others?)

dxpc - The Differential X Protocol Compressor

Original Author: Brian Pane <[email protected]>
Current Maintainer: Zachary Vonler <[email protected]>

This program works in essentially the same way as LBX. However, to
avoid having to implement an X extension and modify the X server code,
dxpc uses _two_ proxies: one that runs on the REMOTE host, like
lbxproxy, and one that runs on the LOCAL host.

The REMOTE host proxy communicates between the X clients and the LOCAL
host proxy, and the LOCAL host proxy communicates between the X server
and the REMOTE host proxy.

So, to _both_ the X clients and the X server, it looks like X protocol
as usual.

Advantages
* Since it's a completely separate application that does not require
any X internals, it's _much_ simpler to compile and install.
* It's maintained separately, so you don't have to wait for the OSF
to release new X versions for enhancements or fixes.
* It provides more and better compression information and statistics
than lbxproxy.

Disadvantages
* It is not a standard part of X; you must obtain and build it
separately.
* It is slightly more complex to set up, since it requires a
LOCAL-side proxy as well as the REMOTE proxy.

Where Can I Get dxpc?

The source for dxpc is available at ftp.x.org.

There is a WWW homepage for dxpc that gives a lot of good information,
including pointers to the dxpc mailing list, access to the source
code, and a number of pre-built binaries for various platforms:

http://ccwf.cc.utexas.edu/~zvonler/dxpc/

Which Is Better?

I don't know. It shouldn't be hard to run some benchmarking against
both LBX and dxpc and get both subjective and statistical measurings
of performance. But I haven't done this, and I don't know of anyone
who has.
_________________________________________________________________

Paul D. Smith

_________________________________________________________________

_Last modified: Thu Jul 17 12:49:24 EDT 1997 _