1DXPC(1) General Commands Manual DXPC(1)
2
3
4
6 dxpc - Differential X Protocol Compressor
7
8
10 3.9.1
11
12
14 dxpc [common] [client | server] [connect]
15
16 [common] options are:
17 -p port_num -f -k -v -s debug_level -l log_file
18
19 [client] options (valid for CLIENT process) are:
20 -i compression_lvl -d display_num -u
21
22 [server] options (valid for SERVER process) are:
23 -D display -b(a|w)
24
25 [connect] options are:
26 hostname -w
27
29 dxpc is an X protocol compressor designed to improve the speed of X11
30 applications run over low-bandwidth links (such as dialup PPP connec‐
31 tions).
32
33 dxpc must be run at both ends of a low-bandwidth link. On the host
34 where the real X server is, dxpc runs in "Server Proxy" mode. On the
35 host at the other end of the link, dxpc runs in "Client Proxy" mode.
36 The Client Proxy dxpc must be started first. When the Server Proxy
37 dxpc is started, it connects to the Client Proxy. (Note that versions
38 of dxpc before 3.3.1 used the opposite convention.) If either of the
39 two communicating dxpc instances is subsequently terminated, the other
40 one automatically shuts down.
41
42 The Client Proxy mimics an X server. X client applications connect to
43 the Client Proxy using display "unix:8" (or "<hostname>:8"; dxpc sup‐
44 ports both UNIX domain and TCP sockets). The Client Proxy receives X
45 requests from the application, compresses them, and sends them to the
46 Server Proxy. The Server Proxy uncompresses the requests and sends
47 them to the real X server. Similarly, the Server Proxy receives X
48 events, replies, and errors from the real X server. It compresses
49 these messages and sends them to the Client Proxy, which uncompresses
50 them and sends them to the client application.
51
52 The compression performance of dxpc depends upon the types of X appli‐
53 cations being run. For many applications, dxpc achieves between 3:1
54 and 6:1 compression of the X protocol traffic.
55
56
58 dxpc has two modes; the connection mode, which is either listening or
59 connecting; and the X mode, which is either client or server.
60
61 The listening process waits for a connecting process to initiate the
62 TCP connection between the two processes. The listening process must
63 always be started first. The connecting process initiates the connec‐
64 tion to the listening process. dxpc will run as the connecting process
65 if a hostname argument is supplied (see connect options, above). Other‐
66 wise it will run as the listening process.
67
68 The server process is typically located on the same machine as the real
69 X server, and is responsible for displaying the output of applications.
70 The client process is typically located on the same machine as the X
71 applications, and is responsible for forwarding the output of those
72 applications to the server process. By default, dxpc runs as the client
73 process if it is the listening process (due to the lack of a hostname
74 argument) and the server process if it is the connecting process, but
75 the -w switch reverses this.
76
77 For example, the command dxpc myhost.work.com starts dxpc as the con‐
78 necting process (because a host name is supplied) and the server
79 process (because it is the connecting process and -w is not supplied).
80 The command dxpc -w starts dxpc as the listening process (because no
81 hostname is supplied) and the server process (because it is the listen‐
82 ing process, and -w reverses the usual logic).
83
84
86 -b(a|w) This option specifies that any windows created should be
87 created with the BackingStore option set to Always (-ba) or
88 WhenMapped (-bw), if the application has not set the option
89 itself. Using the BackingStore option will reduce traffic
90 to repaint exposed regions of the window, at the cost of
91 extra memory use in the X server itself. (This option is
92 ignored in Client Proxy mode.)
93
94 NOTE: The -ba option can cause Expose events to be sent
95 before the client has mapped its windows. This can confuse
96 some client programs, notably GNU Emacs version 20.3. The
97 "bug" in this case is that dxpc shouldn't be setting Back‐
98 ingStore to Always behind the application's back. Never‐
99 less, the option is available, if you want to try it; many
100 client programs still function fine with it, and it will
101 cause the contents of iconified windows to be retained.
102
103
104 -d displaynum
105 This option specifies the number of the X display that dxpc
106 imitates. The default value is 8. (This option is ignored
107 in Server Proxy mode.)
108
109
110 -f This option tells dxpc to fork and run as a daemon process.
111 All subsequent non-error output is suppressed, including
112 statistics reports. The daemon can be killed by use of the
113 -k option.
114
115
116 -k This option tells dxpc to read a pid from the lockfile in
117 the user's home directory and then send a SIGKILL to the
118 old process. It does some error checking to try to ensure
119 that the file contains a valid pid file (and nothing else).
120 The pidfile will exist only if dxpc was started with the -f
121 option.
122
123
124 -l This option is used to tell dxpc to write messages and sta‐
125 tistics to a logfile. Very useful with the -f option.
126
127
128 -p portnumber
129 This option specifies the TCP port number to be used for
130 communication between the Client Proxy and the Server
131 Proxy. The default value is 4000.
132
133
134 -s(1|2) Print a report on dxpc's compression performance for an X
135 application when the application exits. In Client Proxy
136 mode, dxpc displays a report on the compression of messages
137 generated by the X client. In Server Proxy mode, dxpc dis‐
138 plays a report on the compression of messages generated by
139 the X server. The -s1 option yields a simple report that
140 provides the overall compression ratio. The -s2 option
141 yields a far more detailed report on the compression ratios
142 achieved for all the individual message types in the X pro‐
143 tocol. The -s2 option is the "hacker option"; most people
144 will probably want the -s1 report instead.
145
146
147 -u -t Normally, dxpc in Client Proxy mode imitates an X display,
148 :8 by default, by listening on both a UNIX domain socket
149 and a TCP socket. The -u option tells it not to use the
150 UNIX domain port, and the -t option tells it not to use the
151 TCP port. (These options are ignored in Server Proxy
152 mode.)
153
154
155 -v This option tells dxpc to print out its version number and
156 copyright message and exit.
157
158
159 -w Use of this option swaps the connection sequence. That is,
160 the client will initiate the connection to the server.
161 Thus, instead of starting the client like dxpc -f and the
162 server as dxpc -f workserver, you can start the client as
163 dxpc -w -f homepc and the server as dxpc -w -f. This
164 option is intended to be useful for people running the
165 client proxy on a machine behind a firewall.
166
167
168 hostname This argument must be used in Server Proxy mode to tell
169 dxpc the hostname or IP address of the machine where other
170 dxpc (the one in Client Proxy mode) is running. (Note that
171 the presence of this argument is what puts dxpc in Server
172 Proxy mode. If this argument is not used, dxpc runs in
173 Client Proxy mode.)
174
175
176 -D display Specify X host on which to display proxied applications.
177 Defaults to value of the DISPLAY environment variable.
178
179
180 -i(0..9|99|999)
181 This option controls bitmap image compression. This option
182 is only valid on the instance which is accepting connec‐
183 tions; usually this is the client, but the -w option will
184 reverse this, making the -i option valid only on the
185 server. The specified number is the image compression
186 level; higher levels offer better compression at the cost
187 of greater CPU and memory utilization (mostly on the client
188 proxy). The actual behavior of each level is given below.
189
190 0 : No compression (except for the very limited compression
191 supported in dxpc 3.7.0). In other words, behaves like
192 3.7.0 (but is incompatible with it)
193
194 1 : LZO lzo1x_1 compression; very fast, low CPU and memory
195 use, reasonable compression.
196
197 2-9: LZO lzo1c_... variant compression algorithms. lzo1c_2
198 actually seems to be worse than lzo1x_1...
199
200 99: LZO lzo1c_99 algorithm. Slow, but pretty good compres‐
201 sion. NB: I have seen a couple of unexplained crashes when
202 using this level. Not recommended.
203
204 999: LZO lzo1x_999 compression. Slow (but fast enough to
205 feed a 128K ISDN link when hosted on a Pentium II/300 with‐
206 out maxing out the processor), but good compression. This
207 is the default and recommended value.
208
209
210
212 Assume that you're running a real X server on the console of a local
213 workstation called homepc, and that you want to run some X applications
214 on a remote system called workserver and have them display on the con‐
215 sole of the local system.
216
217 On workserver, run
218 $ export DISPLAY=homepc:0
219 $ dxpc -f
220 $ export DISPLAY=unix:8
221
222 On homepc, run
223 $ export DISPLAY=unix:0
224 $ dxpc -f workserver
225
226 Now on workserver,
227 $ xterm&
228 $ xemacs&
229 etc...
230
231
233 If you use X authorization, with a .Xauthority file on the workstation
234 where your real X server runs, you'll need to set up a .Xauthority file
235 on the host where the ClientProxy runs. One way to do this is:
236
237 Copy your ~/.Xauthority file from the host where the real X server runs
238 to the host where the Client Proxy runs.
239
240 Run
241 xauth list
242 to see the authorization keys. There should be one for your real X
243 display. It will look something like this:
244 <hostname>/unix:0 MIT-MAGIC-COOKIE-1 <hex string>
245 On the host where the Client Proxy is located, add a new entry to the
246 .Xauthority file with the display name of the fake X server (the DIS‐
247 PLAY where the Client Proxy is listening) and all of the other values
248 from the entry for the real X display. The xauth "add" command can be
249 used, like this:
250 xauth add <hostname>/unix:8 MIT-MAGIC-COOKIE-1 <hex string>
251 where <hostname> is the name of the host where the Client Proxy is run‐
252 ning and <hex string> has the same value as the <hex string> obtained
253 for the real X display in step 2. Once you do this, you should be able
254 to run X clients through dxpc successfully.
255
256
257
259 Some windows don't appear. This can happen if the -ba option is used,
260 and a client program (such as GNU Emacs version 20.3) does not request
261 backing store and thus assumes that Expose events imply that the window
262 has been mapped. Use -bw, or leave out the -b option altogether.
263
264 No windows appear. This can happen if you are using a newer version of
265 dxpc with an older one, from before the client and server roles were
266 changed. A connection can be established between them, but both sides
267 believe themselves to be the client side, or both sides believe them‐
268 selves to be the server side. Make sure you're using the same version
269 of dxpc at both ends of the connection.
270
271
273 Brian Pane
274
275
277 Kevin Vigor (kevin@vigor.nu)
278
279
281 dxpc has adopted many good ideas from the HBX and FHBX systems
282 (http://www.cs.dartmouth.edu/~jmd/decs/DECSpage.html).
283
284 Thanks to all of the users of dxpc who have contributed feedback and
285 suggestions.
286
287
289 xauth(1), README file from dxpc distribution
290
291
292
293dxpc February 2, 2007 DXPC(1)