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.
|Free Today: September Issue of Linux Journal (Retail value: $5.99)||Sep 27, 2016|
|nginx||Sep 27, 2016|
|Epiq Solutions' Sidekiq M.2||Sep 26, 2016|
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
- Android Browser Security--What You Haven't Been Told
- Readers' Choice Awards 2013
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- Epiq Solutions' Sidekiq M.2
- Nativ Disc
- The Many Paths to a Solution
- Synopsys' Coverity
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Returning Values from Bash Functions
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide