README
1The Simple X Protocol Compressor
2
3This program provides compression of the X protocol stream.
4It is intended to be used to improve the performance of X applications
5over a slow internet connection. (e.g. slip,cslip. or term) It assumes
6a Unix operating system at both ends of the link. Transferring large
7bitmaps or images through sxpc may be slower than not using it.
8The algorithms used are geared primarily for the data exchanged
9during interactive use where the same data may be sent several times
10with only small changes. (e.g. editing)
11
12 WARNING WARNING DANGER DANGER
13 If you use this program use xauth to provide SECURITY, since
14 host-based security will be BYPASSED. See README.xauth.
15
16Compilation:
17sxpc must be compiled and run on both systems.
18
19xmkmf
20make
21If this doesn't work you may have to compile it manually, if your compiler
22claims to be ANSI, but you don't have stdlib.h use -DNOSTDLIBPLEASE, if
23your system is POSIX try -D_POSIX_SOURCE. If your system is vanilla BSD
24cc -I/usr/local/include -o sxpc sxpc.c should just work. If the symbol
25gethostname is undefined try compiling with -DNOGETHOSTNAME.
26(To set any -D flags edit the Makefile or for example:
27make DEFINES="-D_POSIX_SOURCE -DNOHOSTNAME" sxpc)
28
29If you want sxpc to use additional compression and you are not using term
30as your internet link you can get term 1.07 from:
31tartarus.uwa.edu.au:/pub/oreillym/term
32tsx-11.mit.edu:/pub/linux/SLS/a2/term107.tgz
33
34Then compile one file from term and recompile sxpc:
35cd <your term source directory>
36make compress.o
37 (if it fails you may need to edit the Makefile)
38cd <your sxpc source directory>
39make DEFINES=-DTERMCOMPRESS COBJ=<your term source directory>/compress.o
40
41The compression provided by term is best suited for improving interactive performance.
42
43Usage:
44If your internet link is through term see README.term for more information.
45
46On X server host:
47sxpc local $DISPLAY
48
49On X clients' host:
50For csh based shells:
51setenv DISPLAY `sxpc remote $DISPLAY `
52
53For sh based shells:
54DISPLAY=`sxpc remote $DISPLAY`
55export DISPLAY
56(where $DISPLAY is the display setting you would normally use
57to connect to the X server from the clients' host.)
58
59Killing SXPC
60To kill sxpc in your .logout. (or any other time.)
61
62kill `cat /tmp/sxpc.THEDISPLAYARG`
63
64(where THEDISPLAYARG is the value of $DISPLAY used in the sxpc line.)
65
66Thanks To:
67Bill Reynolds (bill@goshawk.lanl.gov) for README.term and README.how.
68Christopher Lau (lau@enel.ucalgary.ca) for bug reporting.
69
70-Rob Ryan
71robr@cmu.edu
72/* sxpc: Transfer compressed X protocol data over a slow network connection.
73 Copyright (C) 1993 Rob Ryan And Carnegie Mellon University - All
74rights reserved
75
76This file is part of sxpc version 1.4.
77sxpc version 1.4 is free software; you can redistribute it and/or modify
78it under the terms of the GNU General Public License as published by
79the Free Software Foundation; either version 1, or (at your option)
80any later version.
81
82sxpc version 1.4 is distributed in the hope that it will be useful,
83but WITHOUT ANY WARRANTY; without even the implied warranty of
84MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
85GNU General Public License for more details.
86
87You should have received a copy of the GNU General Public License
88along with sxpc; see the file COPYING. If not, write to
89the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
90
README.how
1Let's consider an sxpc link between two machines
2on a network: the local machine, L, which runs the X server and the
3remote machine, R, which runs the client. We want run things on
4machine R and to display things on screen 0 of machine L, i.e. L:0.
5To do this using sxpc, on machine L we run the command,
6
7sxpc local :0
8
9on machine R we run the command (assuming csh)
10
11setenv DISPLAY `sxpc remote L:0`
12
13What does this do? If we check $DISPLAY on R, we see that it's
14"localhost:8.0", which means that any client you fire up will try to
15connect to display number 8 on machine R, sxpc will alway set the
16client display to 8 + <true display number>. Thus, since the true
17display number on machine L is 0, the display on R is 8 + 0 = 8. Now
18the X protocol is defined such that display numbers are really unix
19sockets numbered 6000 + <display number>. In other words, your clients
20will try to talk to port 6008 on machine R. On machine R, sxpc listens
21on this port, compresses the information and forwards it to machine L.
22Now, by convention, sxpc daemons communicate with each other using
23port number 4000 + <true display number>. Thus, for display 0 on
24machine L, the sxpc daemon on machine R will try to talk machine L's
25sxpc daemon over port 4000 (4000 + 0 = 4000). After making this
26connection, the sxpc daemon on machine L will take the requests from
27machine R (via port 4000) decompress them and forward them to the
28local server (via port 6000). The following diagram attempts to
29explicate this situation:
30
31 Machine R Machine L
32----------------------- --------------------------
33(client) -----> (sxpc) ---------------> (sxpc) ------> (X server)
34 6008 4000 6000
35
36Bill Reynolds bill@goshawk.lanl.gov
37
README.term
1This document explains how to get sxpc running under term. Term is a
2protocol which provides internet services for a machine connected to a
3networked machine over a serial line. Term was written by Michael
4O'Reilly and is available from tartarus.uwa.edu.au:/pub/oreillym/term.
5This document assumes that you can get term running. If you don't know
6how to run term, read the man page for term_setup.
7
8See QUICK.term for quick info on setting up sxpc with term.
9
10Ok, to get sxpc working with term takes a little thought. To reduce
11the amount of thought, this document sets a few things out. First: how
12does sxpc work? Well, let's consider an sxpc link between two machines
13on a network: the local machine, L, which runs the X server and the
14remote machine, R, which runs the client. We want run things on
15machine R and to display things on screen 0 of machine L, i.e. L:0.
16To do this using sxpc, on machine L we run the command,
17
18sxpc local :0
19
20on machine R we run the command (assuming csh)
21
22setenv DISPLAY `sxpc remote L:0`
23
24What does this do? If we check $DISPLAY on R, we see that it's
25"localhost:8.0", which means that any client you fire up will try to
26connect to display number 8 on machine R, sxpc will alway set the
27client display to 8 + <true display number>. Thus, since the true
28display number on machine L is 0, the display on R is 8 + 0 = 8. Now
29the X protocol is defined such that display numbers are really unix
30sockets numbered 6000 + <display number>. In other words, your clients
31will try to talk to port 6008 on machine R. On machine R, sxpc listens
32on this port, compresses the information and forwards it to machine L.
33Now, by convention, sxpc daemons communicate with each other using
34port number 4000 + <true display number>. Thus, for display 0 on
35machine L, the sxpc daemon on machine R will try to talk machine L's
36sxpc daemon over port 4000 (4000 + 0 = 4000). After making this
37connection, the sxpc daemon on machine L will take the requests from
38machine R (via port 4000) decompress them and forward them to the
39local server (via port 6000). The following diagram attempts to
40explicate this situation:
41
42 Machine R Machine L
43----------------------- --------------------------
44(client) -----> (sxpc) ---------------> (sxpc) ------> (X server)
45 6008 4000 6000
46
47Now, how do we get this to work using term? With term, there is a
48third machine, machine T, not connected to the net, which obtains all
49it's network services from machine L over a serial line. We want a
50client running on machine R to display on machine T via machine L. We
51do this by exploiting the fact that sxpc uses port 4000 to
52communicate. We will redirect port 4000 on machine L to machine T, and
53run sxpc on machine T. In this way, the compressed data will go out
54over the modem, speeding up the link. (This really works, I find
55graphical data especially peppy using sxpc).
56
57Under this scheme, the previous diagram is amended as follows:
58
59
60Machine R Machine L Machine T
61------------------- ---------- -----------------------
62(client) --> (sxpc) ------------> (tredir) --------> (sxpc) ----> (X server)
63 6008 4000 term 6000
64
65
66In other words, we run the following sequence of commands:
67
68On machine R:
69
70setenv DISPLAY `sxpc remote L:0`
71
72(it looks like we want to use the main display on machine L, but
73that's not the case, read on!)
74
75
76On machine L (after we've set up term between it and machine T):
77
78tredir 4000 4000
79
80(now whoever opens port 4000 on machine L will really be talking to
81port 4000 on machine T)
82
83
84On machine T:
85
86sxpc local localhost:0
87
88(anybody who talks to port 4000 will get forwarded to the local X
89server).
90
91Now, any client that runs on machine R will display on machine T!
92That's all there is to it :-).
93
94What we've just described is the most general case. Oftentimes, you
95just want to run an X client on the other end of your term link, i.e.
96we're just going from machine R to machine T (we're dumping machine
97L). Machine R is hooked up to machine T via term, and we want to run a
98client on R and have it display on T. We represent this situation with
99the following diagram:
100
101
102 Machine R Machine T
103-------------------------------------- ----------------------
104(client) ------> (sxpc) -----> (tredir) --------> (sxpc) -----> (Xserver)
105 6008 4000 term 6000
106
107
108To realize this situation, we run the following commands (after we've
109set up the term link between R and T):
110
111On machine R:
112
113tredir 4000 4000
114setenv DISPLAY `sxpc remote localhost:0`
115
116(again it looks like we're setting things up to run on the local
117machine, but we're not, through the magic of tredir)
118
119
120On machine T:
121sxpc local localhost:0
122
123Now, any client you run on machine R will display on machine T.
124
125Well, that should do it. Good luck!
126
127Bill Reynolds bill@goshawk.lanl.gov
128
README.xauth
1/* sxpc: Transfer compressed X protocol data over a slow network connection.
2 Copyright (C) 1993 Rob Ryan And Carnegie Mellon University - All
3rights reserved
4
5This file is part of sxpc version 1.4.
6sxpc version 1.4 is free software; you can redistribute it and/or modify
7it under the terms of the GNU General Public License as published by
8the Free Software Foundation; either version 1, or (at your option)
9any later version.
10
11sxpc version 1.4 is distributed in the hope that it will be useful,
12but WITHOUT ANY WARRANTY; without even the implied warranty of
13MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
14GNU General Public License for more details.
15
16You should have received a copy of the GNU General Public License
17along with sxpc; see the file COPYING. If not, write to
18the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */
19
20WHY USE XAUTH
21Using xauth is very important to maintaining security when using sxpc. If you do not use xauth when using sxpc all the dangers of running with "xhost +" apply. These dangers include but are not limited to:
22
23someone watching what is displayed on your screen, or what you type.
24someone typing in one of your windows (for example: a command to delete all your files :-(
25
26xauth is available in X releases R4 and later. In this document I will describe how to set up basic usage of xauth. This configuration is vulnerable to network snooping, but if you can live with that it should be fine.
27
28See the xauth manual page for information on moving authorization information from one host to another.
29See the manual page for Xsecurity for information about other protocols to use in place of MIT-MAGIC-COOKIE-1. (Note that the other protocols use different kinds of keys.)
30
31HOW TO USE XAUTH
32NOTE: when using xauth your $DISPLAY variable must NOT be set to localhost. (or localhost:whatever) If your $DISPLAY variable does use localhost the clients will be unable to find the appropriate authorization information. The workaround is to use the real hostname of the machine. If you follow the compilation instructions in the README, and compile without -DNOGETHOSTNAME then everything should work.
33
34The machine where you will be running clients will be called C, the machine where you wish to display them will be called D.
35
36First choose a "key", up to 16 pairs of hexadecimal digits. (so an even number of characters from the ranges 0-9 and a-f) You will need to supply this key in place of <key> in the example below.
37
38On C:
39
40% xauth
41xauth: creating new authority file ~/.Xauthority
42Using authority file ~/.Xauthority
43xauth> add Chostname:8 MIT-MAGIC-COOKIE-1 <key>
44xauth> exit
45
46On D:
47
48% xauth
49xauth: creating new authority file ~/.Xauthority
50Using authority file ~/.Xauthority
51xauth> add Dhostname/unix:0 MIT-MAGIC-COOKIE-1 <key>
52xauth> add Dhostname:0 MIT-MAGIC-COOKIE-1 <key>
53xauth> exit
54
55When starting the X server on D you should give the flag -auth $HOME/.Xauthority. You may need to edit or create a $HOME/.xserverrc to control how the X server is started. For example:
56
57#!/bin/sh
58exec X -auth $HOME/.Xauthority $*
59
60On both C and D:
61Make sure that your .Xauthority file is readable only by you.
62