The LBX Mini-HOWTO
Paul D. Smith, v1.04, 11 December 1997
LBX (Low Bandwidth X) is an X server extension which performs compression on the X protocol. It is meant to be used in conjunction with X applications and an X server which are separated by a slow network connection, to improve display and response time.
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.
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.
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.
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.
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 (
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.
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
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
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.
lbxproxy is simply a single executable. There are
no configuration files, resource files, etc. associated with it.
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.
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!)
- Start your X server.
- Tell your X server that the remote system is allowed access.
Using the host-list method, type
xhost +REMOTE. If you use
xauthyou may need to do more than this; see the xauth(1) man page for more information. You should consult the Remote X Apps Mini-HOWTO if you're not familiar with remote X access permission setup.
lbxproxyand tell it to forward to the LOCAL X server, like this:
$ lbxproxy -display LOCAL:0 :1 &
lbxproxyto use display
:1on the REMOTE system; if that system has >1 display already you can use
:2or whatever instead.
- Set your DISPLAY environment variable to point to the display
lbxproxyis providing, instead of the normal display:
$ DISPLAY=:1 $ export DISPLAY
% setenv DISPLAY :1
- If you're using
xauthyou will need to ensure that your cookie is available locally. See the Remote X Apps Mini-HOWTO for more information on this.
- 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
have both running at the same time.
Here are some common problems:
lbxproxyexits with an "access denied" error.
This means the LOCAL system isn't accepting connections from the REMOTE system due to permissions errors. See the Remote X Apps Mini-HOWTO for details on these issues.
As a simple trouble-shooting measure, try running a simple X app like
xclockon REMOTE and have it display on the local system without using
$ xclock -display LOCAL:0
If that doesn't work, it's
xhostor some other basic X problem, not LBX.
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:
More detailed discussion of specific LBX algorithms is available here:
If you don't have access to the X11 source, you can obtain these files from the X Consortium's FTP site.
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
dxpc 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
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.
- 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
- 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:
document.write( '' );
document.write( addy_text854 );
document.write( '<\/a>' );
ssh can be used for
compression. Although its main purpose is to provide security, it
also compresses the data it sends.
Thus, if you run X over a
ssh link you will
automatically obtain some amount of compression.
I don't know. Both LBX and
dxpc are certainly better
at raw compression than
ssh. Of course,
ssh provides the added advantage of security. And of
course, there's no reason you can't use both
one of the other two, to get good compression and security.
It shouldn't be hard to run some benchmarking against these options and get both subjective and statistical measurings of performance. But I haven't done this, and I don't know of anyone who has.