6. X and 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 + foo

  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.