Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
DXPC(1)			    General Commands Manual		       DXPC(1)

       dxpc - Differential X Protocol Compressor


       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

       dxpc  is	 an X protocol compressor designed to improve the speed	of X11
       applications run	over low-bandwidth links (such as dialup  PPP  connec-

       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 sup-
       ports 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	appli-
       cations	being  run.   For many applications, dxpc achieves between 3:1
       and 6:1 compression of the X protocol traffic.

       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 connec-
       tion to the listening process. dxpc will	run as the connecting  process
       if a hostname argument is supplied (see connect options,	above).	Other-
       wise 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 ap-
       plications 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 starts dxpc as the con-
       necting 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 listen-
       ing process, and	-w reverses the	usual logic).

       -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 be-
		   fore	 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 Back-
		   ingStore to Always behind the application's	back.	Never-
		   less,  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

       -l	   This	option is used to tell dxpc to write messages and sta-
		   tistics 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 dis-
		   plays 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 pro-
		   tocol.   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

       -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  op-
		   tion	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.

		   This	option controls	bitmap image compression. This	option
		   is  only  valid  on the instance which is accepting connec-
		   tions; 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 compres-
		   sion. 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 with-
		   out	maxing	out the	processor), but	good compression. This
		   is the default and recommended value.

       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  con-
       sole 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&

       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.

	   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  DIS-
       PLAY  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 run-
       ning 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.

       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	 them-
       selves  to be the server	side.  Make sure you're	using the same version
       of dxpc at both ends of the connection.

       Brian Pane

       Kevin Vigor (

       dxpc has	adopted	 many  good  ideas  from  the  HBX  and	 FHBX  systems

       Thanks  to  all	of the users of	dxpc who have contributed feedback and

       xauth(1), README	file from dxpc distribution

dxpc			       February	2, 2007			       DXPC(1)


Want to link to this manual page? Use this URL:

home | help