The LBX Mini-HOWTO Paul D. Smith 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 Dale Tonogai Keith Packard Jim Fulton Chris Kanterjiev [...] 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 [...] -------------------------------------------------------------------------------