A Tale of DXPC: Differential X Protocol Compression

When you have a slow modem and want faster transfer rates, data compression with this program is the answer.

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.

Client/Server Configuration

Install

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.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix