DXPC(1)

📦 version 3.9.2, in fedora 43, fedora 44

dxpc(1) — Differential X Protocol Compressor 💖

okay bestie, welcome to the DXPC page, from the General Commands Manual section. This is the manual for dxpc, and it is iconic, no cap.

RELEASE ⭐

3.9.1

SYNOPSIS ✨

dxpc [common] [client | server] [connect]

[common] options are:

-p port_num -f -k -v -s debug_level -l log_file

[client] options (valid for CLIENT process) are:

-i compression_lvl -d display_num -u

[server] options (valid for SERVER process) are:

-D display -b(a|w)

[connect] options are:

hostname -w

DESCRIPTION 🦋

So dxpc is an X protocol compressor — it's literally designed to make X11 applications go faster when they're running over low-bandwidth links (think dialup PPP connections, the struggle was real 😭).

The tea: dxpc has to be running at both ends of that low-bandwidth link. On the host where the real X server lives, dxpc runs in "Server Proxy" mode. On the host at the other end of the link, dxpc runs in "Client Proxy" mode. The Client Proxy dxpc must be started first. When the Server Proxy dxpc starts up, it connects to the Client Proxy. (Side note bestie: versions of dxpc before 3.3.1 used the opposite convention, so watch out for old docs 💀.) And if either of the two communicating dxpc instances gets terminated, the other one automatically shuts down too. Ride or die, literally.

The Client Proxy mimics an X server. X client applications connect to the Client Proxy using display "unix:8" (or "<hostname>:8"; dxpc supports both UNIX domain and TCP sockets, versatile queen ✨). The Client Proxy receives X requests from the application, compresses them, and sends them to the Server Proxy. Then the Server Proxy uncompresses those requests and sends them on to the real X server. Same energy in reverse: the Server Proxy receives X events, replies, and errors from the real X server, compresses them, sends them to the Client Proxy, which uncompresses them and hands them to the client application. 🫶

And the compression performance of dxpc? Depends on what X applications you're running, obviously. But for many applications, dxpc achieves between 3:1 and 6:1 compression of the X protocol traffic. Slay.

MODES 💅

dxpc has two modes, keep up:

  • the connection mode, which is either listening or connecting; and
  • the X mode, which is either client or server.

The listening process waits for a connecting process to initiate the TCP connection between the two processes. The listening process must always be started first. The connecting process initiates the connection to the listening process. dxpc will run as the connecting process if a hostname argument is supplied (see connect options, above). Otherwise it will run as the listening process.

The server process is typically located on the same machine as the real X server, and it's the one responsible for displaying the output of applications. The client process is typically located on the same machine as the X applications, and it's responsible for forwarding the output of those applications to the server process. By default, dxpc runs as the client process if it's the listening process (because there's no hostname argument) and as the server process if it's the connecting process — but the -w switch reverses all of that. Plot twist. 🙈

For example, the command dxpc myhost.work.com starts dxpc as the connecting process (because a host name is supplied) and the server process (because it's the connecting process and -w is not supplied). The command dxpc -w starts dxpc as the listening process (because no hostname is supplied) and the server process (because it's the listening process, and -w reverses the usual logic).

Options 🎀

  • -b(a|w) — says that any windows created should be created with the BackingStore option set to Always (-ba) or WhenMapped (-bw), if the application hasn't set the option itself. Using BackingStore reduces traffic to repaint exposed regions of the window, at the cost of extra memory use in the X server itself. (This option is ignored in Client Proxy mode.)
NOTE: the -ba option can cause Expose events to be sent before the client has mapped its windows. This can confuse some client programs, notably GNU Emacs version 20.3. The "bug" in this case is that dxpc shouldn't be setting BackingStore to Always behind the application's back. Nevertheless, the option is available, if you want to try it; many client programs still function fine with it, and it will cause the contents of iconified windows to be retained.
  • -d displaynum — specifies the number of the X display that dxpc imitates. The default value is 8. (This option is ignored in Server Proxy mode.)
  • -f — tells dxpc to fork and run as a daemon process. All subsequent non-error output is suppressed, including statistics reports. The daemon can be killed by use of the -k option.
  • -k — tells dxpc to read a pid from the lockfile in the user's home directory and then send a SIGKILL to the old process. It does some error checking to try to ensure that the file contains a valid pid file (and nothing else). The pidfile will exist only if dxpc was started with the -f option.
  • -l — used to tell dxpc to write messages and statistics to a logfile. Very useful with the -f option.
  • -p portnumber — specifies the TCP port number to be used for communication between the Client Proxy and the Server Proxy. The default value is 4000.
  • -s(1|2) — print a report on dxpc's compression performance for an X application when the application exits. In Client Proxy mode, dxpc displays a report on the compression of messages generated by the X client. In Server Proxy mode, dxpc displays a report on the compression of messages generated by the X server. The -s1 option yields a simple report that provides the overall compression ratio. The -s2 option yields a far more detailed report on the compression ratios achieved for all the individual message types in the X protocol. The -s2 option is the "hacker option"; most people will probably want the -s1 report instead.
  • -u -t — normally, dxpc in Client Proxy mode imitates an X display, :8 by default, by listening on both a UNIX domain socket and a TCP socket. The -u option tells it not to use the UNIX domain port, and the -t option tells it not to use the TCP port. (These options are ignored in Server Proxy mode.)
  • -v — tells dxpc to print out its version number and copyright message and exit.
  • -w — use of this option swaps the connection sequence. That is, the client will initiate the connection to the server. So instead of starting the client like dxpc -f and the server as dxpc -f workserver, you can start the client as dxpc -w -f homepc and the server as dxpc -w -f. This option is intended to be useful for people running the client proxy on a machine behind a firewall. 🔥
  • hostname — this argument must be used in Server Proxy mode to tell dxpc the hostname or IP address of the machine where the other dxpc (the one in Client Proxy mode) is running. (Note that the presence of this argument is what puts dxpc in Server Proxy mode. If this argument is not used, dxpc runs in Client Proxy mode.)
  • -D display — specify X host on which to display proxied applications. Defaults to value of the DISPLAY environment variable.
  • -i(0..9|99|999) — controls bitmap image compression. This option is only valid on the instance which is accepting connections; usually this is the client, but the -w option will reverse this, making the -i option valid only on the server. The specified number is the image compression level; higher levels offer better compression at the cost of greater CPU and memory utilization (mostly on the client proxy). The actual behavior of each level is given below.
    • 0 : No compression (except for the very limited compression supported in dxpc 3.7.0). In other words, behaves like 3.7.0 (but is incompatible with it)
    • 1 : LZO lzo1x_1 compression; very fast, low CPU and memory use, reasonable compression.
    • 2-9: LZO lzo1c_... variant compression algorithms. lzo1c_2 actually seems to be worse than lzo1x_1... 😭
    • 99: LZO lzo1c_99 algorithm. Slow, but pretty good compression. NB: I have seen a couple of unexplained crashes when using this level. Not recommended. 💀
    • 999: LZO lzo1x_999 compression. Slow (but fast enough to feed a 128K ISDN link when hosted on a Pentium II/300 without maxing out the processor), but good compression. This is the default and recommended value. 👑

EXAMPLES 🌸

Assume that you're running a real X server on the console of a local workstation called homepc, and that you want to run some X applications on a remote system called workserver and have them display on the console of the local system.

On workserver, run:

$ export DISPLAY=homepc:0
$ dxpc -f
$ export DISPLAY=unix:8

On homepc, run:

$ export DISPLAY=unix:0
$ dxpc -f workserver

Now on workserver:

$ xterm&
$ xemacs&
etc...

🔐 DXPC AND XAUTH 🔐

okay bestie, listen up, because this part is lowkey the make-or-break moment 🫶

So if you're running X authorization, and you've got a .Xauthority file sitting on the workstation where your real X server lives, you're gonna need to set up a .Xauthority file over on the host where the ClientProxy is running too. Like, it needs its own. No cap. One way to do this is:

  1. Copy your ~/.Xauthority file from the host where the real X server runs over to the host where the Client Proxy runs. 🚚
  2. Run
xauth list

to see the authorization keys. There should be one for your real X display, and it'll look something like this:

<hostname>/unix:0   MIT-MAGIC-COOKIE-1   <hex string>
  1. On the host where the Client Proxy lives, add a new entry to the .Xauthority file — use the display name of the fake X server (that's the DISPLAY where the Client Proxy is listening, not the real one bestie) and keep all the other values from the entry for the real X display. The xauth "add" command is your girl here, like this:
xauth add <hostname>/unix:8 MIT-MAGIC-COOKIE-1  <hex string>

where <hostname> is the name of the host where the Client Proxy is running, and <hex string> has the exact same value as the <hex string> you got for the real X display back in step 2. 👑

Once you've done all that, you should be able to run X clients through dxpc successfully. slay. ✨

🚨 TROUBLESHOOTING 🚨

Some windows don't appear. 😭 This can happen if the -ba option is used, and a client program (such as GNU Emacs version 20.3) doesn't request backing store — so it just assumes that Expose events mean the window has been mapped. Rude of it, honestly. Use -bw instead, or just leave out the -b option altogether. periodt.

No windows appear. 💀 This one can happen if you're using a newer version of dxpc with an older one — like, from before the client and server roles were changed. A connection can be established between them, but then both sides believe themselves to be the client side, or both sides believe themselves to be the server side. It's giving two people both trying to be the little spoon. 🥄 Make sure you're using the same version of dxpc at both ends of the connection, bestie. fr fr.

✍️ AUTHOR ✍️

Brian Pane 🌟

🛠️ MAINTAINER 🛠️

Kevin Vigor (kevin@vigor.nu) 💌

🫶 ACKNOWLEDGMENTS 🫶

dxpc has adopted many good ideas from the HBX and FHBX systems (http://www.cs.dartmouth.edu/~jmd/decs/DECSpage.html). iconic behaviour honestly.

Thanks to all of the users of dxpc who have contributed feedback and suggestions. that's you, maybe!! 💖

👀 SEE ALSO 👀

  • xauth(1)
  • README file from dxpc distribution

and that's a wrap on the whole page, bestie!! 🎀 this was dxpc from February 2, 2007, filed under DXPC(1). go forth and compress those X connections, you absolute main character 👑💅🦋

📦 where this page comes from