A Tale of DXPC: Differential X Protocol Compression

Once upon a time there was a frustrated engineer who needed a faster way to remotely display X clients on his home PC. He had a new daughter, and very much wished to spend time with her without driving back and forth to work. One day a fellow engineer told him about a fantastic little program called DXPC. Could it be true? Were all of his problems solved? No, but at least they were improved.

DXPC stands for Differential X Protocol Compression. It is a small client/server program that runs on both sides of a low bandwidth link (e.g., 28.8K modem PPP link), and is designed to exploit “features” in the X protocol to speed up the remote display of applications across the link. It is capable of compressing the X messages as much as 10:1. However, not all messages receive such great performance. Some messages are not compressed at all. On the average, you can expect as much as 4:1 compression. This sweet little jewel was originally written by Brian Pane and further developed by Zachary Vonler.

DXPC employs six different compression techniques. First, it strips unnecessary data fields. Next, it shrinks fields with a limited number of possibilities (i.e., Boolean). Using similar techniques, it shrinks fields that are typically small, while still handling the cases where they are large. The fourth method uses a cache on each side of the link to store different command types. With this cache, instead of transmitting full coordinates, it transmits a much smaller differential value based on the previously sent command. Additionally, a cache of the last six deltas is stored so that it can do further encoding based on a pattern of deltas. Lastly, DXPC caches large blocks of data that are transmitted more than once (e.g., X resources). DXPC also employs a text compressor and an image compressor. For a more detailed description of these techniques, the authors have included a text file called DESIGN which describes how DXPC works.

DXPC is a client/server application, but the client and server are the same executable. The client side is the remote site or the site where the X applications are executed. The server side is the local site or the site where the X application is displayed. You must be able to compile DXPC and run it on the remote site and the local site. Fortunately, the authors have done most of the porting work for you. DXPC uses autoconf and will compile on most UNIX platforms right out of the “box”. Additionally, there are ports to Win32 and OS/2. I compiled it for Red Hat Intel Linux (local) and Solaris 2.5.1 (remote) without a hitch. Well, one speed bump; I had to add the options -lnsl -lsocket to the LIBS line in the Makefile for Solaris. I have sent this little gnat to the authors, so hopefully it will be fixed in the 3.6 release.

Perform the steps below on both your local station and on the remote site. Once you have completed this, you are ready to go.

tar xzvf dxpc-3.5.0.tar.gz
cd dxpc-3.5.0
./configure # optionally add --prefix=/home/bubba
make
make install
make install.man

Now the moment of triumph—let’s look at an example. At work, you have a Sun box running Solaris. On this machine, named workhog, you normally run some expensive CAE (Common Applications Environment) tools that are not available for Linux. (If only these vendors realized the power of Linux.) At home, you have a Linux box named linuxrules that you want to be able to use for more than Quake and Netscape. You have already compiled and installed DXPC on both machines, and are sitting at home wanting to do some work. You boot up linuxrules, and establish a PPP connection across that pathetic 28.8K modem to workhog. On the screen are two xterms, or rxvts. One xterm is attached to linuxrules, the other to workhog.

Inside the workhog xterm, type the following three simple commands:

setenv DISPLAY linuxrules:0.0
dxpc -f -s1
setenv DISPLAY unix:8

Then, in the linuxrules xterm, type this one simple command:

dxpc -f workhog -s1

Now you are ready to go. In the workhog xterm, start your very expensive CAE tool. Suddenly, it’s as if your modem has turned into a T1 line. Well, not quite, but hopefully it is faster than before and fast enough to be useful. The -s1 argument is optional and will report level 1 statistics on the compression ratio. There is also a level 2 statistics argument, -s2, which prints statistics on all message types sent.

The compression methods used by DXPC are compressions that cannot be done by hardware compression in the modem. In fact, I believe it complements other compression techniques to increase overall performance. The authors have done an excellent job of developing and maintaining a stable, easily compiled and easy to use program. I wish I had found it a year ago. Please note that if you use X authority with a .Xauthority file, some extra steps are necessary to use DXPC. These steps are covered in the README file distributed with the source.

Brian Pane informs me that they are preparing to release DXPC 3.6.0 soon. He has added compression for more X messages.