TERM
TERM allows users to open up X windows on the local machine
from clients that are running on a machine on the network. This is
done by using the txconn client. txconn is
executed on the remote, network-connected machine; it is invoked
simply as txconn. It goes into the background and returns a
number on the standard output; this number is the display number that
clients should use to access the X server on the local machine. An
example should make this clear. I am logged in, via trsh,
to my remote TERM host, named foo. On foo, I do the following
foo$ txconn Xconn bound to screen 10 :10 foo$
Now, on any host that I wish to run an X client on, that is to display on my local machine's X server, I do
setenv DISPLAY foo:10
(for bash you should use export DISPLAY=foo:10). In some cases it can furthermore be necessary to do a
xhost + fooor even a
xhost +
on your local machine. Now when I start the client, it will try to connect to
screen 10 on machine foo, but txconn is listening to
this screen, and will forward all X protocol packets via TERM
to the X server on the local host - i.e. the window will open
up on your local machine.
It is possible to go the other way - run a client on your local machine and have it open up a window on a remote machine on the network; however we will defer explaining this until after we have discussed tredir.
The X protocol is not very efficient; it wastes some bandwidth. This
is usually not a problem over an ethernet, but can be murder over a
modem. X11R6 is supposed to introduce a low bandwidth version of the X
protocol, LBX. If however you are using X11R5 you can use a utility named sxpc which compresses the X protocol, improving response over
serial lines. Sxpc includes a write-up on how to get it
working with TERM, and is recommended. The sxpc package also explains how to use xauth; so it is
doubly recommended.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter
Return to Welcome Home Page