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 -s1Now 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.
- Android Candy: Google Keep
- Readers' Choice Awards 2014
- A Little GUI for Your CLI
- Handling the workloads of the Future
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- diff -u: What's New in Kernel Development
- Synchronize Your Life with ownCloud
- Days Between Dates?
- December 2014 Issue of Linux Journal: Readers' Choice
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane