NAME¶
dxpc - Differential X Protocol Compressor
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¶
dxpc is an X protocol compressor designed to improve the speed of X11
applications run over low-bandwidth links (such as dialup PPP connections).
dxpc must be run at both ends of a low-bandwidth link. On the host where the
real X server is, 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 is
started, it connects to the Client Proxy. (Note that versions of dxpc before
3.3.1 used the opposite convention.) If either of the two communicating dxpc
instances is subsequently terminated, the other one automatically shuts down.
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). The Client Proxy receives X
requests from the application, compresses them, and sends them to the Server
Proxy. The Server Proxy uncompresses the requests and sends them to the real X
server. Similarly, the Server Proxy receives X events, replies, and errors
from the real X server. It compresses these messages and sends them to the
Client Proxy, which uncompresses them and sends them to the client
application.
The compression performance of dxpc depends upon the types of X applications
being run. For many applications, dxpc achieves between 3:1 and 6:1
compression of the X protocol traffic.
MODES¶
dxpc has two modes; 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 is responsible for displaying the output of applications. The
client process is typically located on the same machine as the X
applications, and is responsible for forwarding the output of those
applications to the
server process. By default, dxpc runs as the
client process if it is the
listening process (due to the lack
of a hostname argument) and the
server process if it is the
connecting process, but the -w switch reverses this.
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 is 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 is the
listening process, and -w reverses the usual logic).
Options¶
- -b(a|w)
- This option specifies that any windows created should be
created with the BackingStore option set to Always ( -ba) or
WhenMapped ( -bw), if the application has not set the option
itself. Using the BackingStore option will reduce 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. Neverless, 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
- This option specifies the number of the X display that dxpc
imitates. The default value is 8. (This option is ignored in Server Proxy
mode.)
- -f
- This option 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
- This option 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
- This option is used to tell dxpc to write messages and
statistics to a logfile. Very useful with the -f option.
- -p portnumber
- This option 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
- This option 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. Thus, 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 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)
- This option 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¶
If you use X authorization, with a .Xauthority file on the workstation where
your real X server runs, you'll need to set up a .Xauthority file on the host
where the ClientProxy runs. One way to do this is:
Copy your ~/.Xauthority file from the host where the real X server runs to the
host where the Client Proxy runs.
Run
xauth list
to see the authorization keys. There should be one for your real X display. It
will look something like this:
<hostname>/unix:0 MIT-MAGIC-COOKIE-1 <hex string>
On the host where the Client Proxy is located, add a new entry to the
.Xauthority file with the display name of the fake X server (the DISPLAY where
the Client Proxy is listening) and all of the other values from the entry for
the real X display. The xauth "add" command can be used, 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 same value as the <hex string> obtained
for the real X display in step 2. Once you do this, you should be able to run
X clients through dxpc successfully.
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) does not request
backing store and thus assumes that Expose events imply that the window has
been mapped. Use
-bw, or leave out the
-b option altogether.
No windows appear. This can happen if you are using a newer version of
dxpc with an older one, from before the client and server roles were changed.
A connection can be established between them, but both sides believe
themselves to be the client side, or both sides believe themselves to be the
server side. Make sure you're using the same version of dxpc at both ends of
the connection.
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).
Thanks to all of the users of dxpc who have contributed feedback and
suggestions.
SEE ALSO¶
xauth(1), README file from dxpc distribution