'Scuse my jumping in and adding another $0.02 to the various comments so far...
> <sniplet>
> All of this is confusing at first, since it isn't really like the
> client-server models for just about everything else (http, ftp,
> etc.).
Actually, it is the same, but you have to think through the reasoning:
With a file server, the *resource* is the files; with a print server, the
resource is the printer(s); with a hypertext server (http), the resource is the
hypertext.
In each of these cases, the *server* is located where the *resource* is
located. The *clients* connect accross the network to the server to gain access
to the resource(s).
With X, the *resource* is the display (video, keyboard, mouse). The *server*
runs where the resource is located (on the machine that has the display). The
*clients* run anywhere on the network and attach to the server to access the
server's resources-- that is, to get mouse and keyboard input and to output
images.
> Can I ask two question please - what are things like xterm and
> fvwm and where do they fit in to the model?
fvwm is a window manager, a special client. It usually runs on the same host as
the server but doesn't have to...
Xterm is a regular client that performs a bit of a unique function. It connects
two interfaces together. On the one side, it presents a psudeo-tty interface,
which character apps expect to use to talk to a character terminal (like a Wyse
60 or a VT100). On the other side it connects to an X server. It is basically
an adapter that allows character-based apps to work in the graphical world of X
Windows.
The interesting part of this is that you can use a remote connection on either
the psudeo-tty side of xterm or on the X side of xterm. Thus if you have
machine A and machine B, and you have an X server on A and a character-based
client on B, you can run the xterm on machine A and use telnet to connect to B;
or you can run the xterm on B. In the first case, the character-based app talks
to a telnet server through the pseudo-tty on machine B, and the character data
is moved across the network to machine A and passed (again through the
psudeo-tty interface) to the xterm, which in turn speaks to the X server using
the X protocol. Thus what is travelling across the network is character-based
data as would travel to and from a serial terminal. In the second case, the
character-based app talks through the psudeo-tty interface to the xterm client
*on the same machine*, which then talks to the remote X server using the X
protocol. In this case, the traffic across the network is the graphic-based (X)
data. In almost all cases, the character-based data is more compact than the X
protocol, so for efficient network utilization, you will usually want to use
the first case... though there are exceptions, such as when a specific xterm
emulation is only available on one of the machines (yes, there are different
xterms with different emulations).
> I've managed to get Windows xservers to run like Hummingbird,
> X-WinPro and TNTlite Mx but never really understood the xterm bit.
> I had to do a *lot* of faq-searching to work out I was supposed to
> set DISPLAY to 0.0 to get xterm to run. What is the significance
> of the DISPLAY parameter?
DISPLAY tells an xclient which X server to connect to. It takes the form:
[host]:display[.screen]
Thus to connect to screen 0 of display 0 on host foo.com, set DISPLAY to:
foo.com:0.0
To connect to screen 1 of display 2 on host bar.net, set DISPLAY to:
bar.net:2.1
This is almost never used because most systems only have one display (keyboard,
mouse, screen) and most displays have only one screen (although you can do up
to 8 monitors as one giant display using, say, Accelerated-X from XIG).
In order for DISPLAY to work on a remote host, the host must be accepting
connections from the client (it doesn't have to). By default, most X servers
will accept connections only from the local machine. At a basic level you can
use:
xhost +
To let any host connect to an X server, or you can use
xhost +hostname
To let "hostname" connect to the X server. You can also use xauth to do this in
a more-secure manner (e.g., the remote client must know a magic-cookie (key) to
access the X server).
There are "special" hostnames, too: "unix" and "". Usually, DISPLAY is set to
":0.0" (meaning screen 0 of display 0 on the local host). Most clients will use
a non-TCP/IP means of connection (Unix domain sockets, named pipes, shared
memory, etc. depending on your system) in this case; by skipping TCP/IP the
performance will be improved (but of course this only works locally).
OK, that's enough rambling :-) Hope this is helpful.
--
Chris Tyler <[EMAIL PROTECTED]>
Global Proximity Corporation http://Global.Proximity.ON.CA/
Internet and Computer Consulting (519) 469-3439 / fax (519) 469-8653
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
