The LBX Mini-HOWTO
Paul D. Smith <psmith@BayNetworks.com>
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 <lemke@ncd.com>
Dale Tonogai <dct@ncd.com>
Keith Packard <keithp@ncd.com>
Jim Fulton <jim@ncd.com>
Chris Kanterjiev <cak@parc.xerox.com>
[...]
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
[...]
-------------------------------------------------------------------------------