Re: Not meant to be flame bait, but...

jared_at_hwai.com (Jared) writes:

> I'm confused. I thought an X server ran on the machine accessing the
> app (i.e., X server/client works the opposite of the classical
> definition of server/client). Are you saying that the 6i Forms server
> is acting as its own client to put a Forms app out via 9iAS?
>
> That aside, my plan was to run both machines headless; nor have I ever
> needed a direct-attach monitor and keyboard to do a *nix-based
> installation, though I am afraid the same is not true in the M$ world.
>

I will try to clarify a bit. I will abstract a bit to try to avoid some of the less relevant and more complex aspects not really necessary in a (hopefully) clearer high level description.

In a typical X windows setup, you have three layers of abstraction - the X server, the X display manager and the X window manager. The X server is the lowest level tier and handles communication with your graphics hardware. The x display manager handles the management of the various clients which may connect to a host. In a thin client situation, each client would run its own X server, but all clients might connect to the same display manager on a remote server. Under systems like Linux, you don't have to run an X display manager if you only have a single "client" - you would login at the console and enter a command like 'startx' to open an X session. However, usually you do run an X display manager so that you can login directly to X without having to first login to a console and then issue the startx command. You can think of the X display manager as a type of router for the X protocol which ensures the display requests are routed to the correct X server etc.

The third layer is the X window manager. This layer controls the manipulation (and often decoration) of windows - provides facilities for window placement, sizing, iconifying etc. You can run most X applications without a window manager, but you won't have the high level window manipulation support you have when you run a window manager. There are many different window managers available offering varying levels of functionality. One of the oldest and simplest is twm. Often, X setups have a "failsafe" mode which will run if for some reason during login the system was unable to run your window manager. this failsafe mode usually will just open an Xterm which will allow you to investigate and hopefully fix the problem.

When you start an X session, the X display manager initializes a variable called DISPLAY. This variable usually consists of three parts - hostname of the X server, the display number and the screen number in the form hostname:display.screen. Often, when running X apps on the same system as the X server, this variable will just contain the display and screen values e.g. :0.0. The screen part is nearly always 0 unless you have a multi-headed display, in which case each "head" will be numbered from 0 to n where n is the number of heads.

When you connect to a remote server and execute an X application, the app will look for the display variable setting to determine which host to send the display requests to, which display on that host to communicate with and which screen of that display to use. Control of connections to the display are usually handled via either the xhosts or xauth commands. The xhosts command is usually avoided because it is a host based authentication method. As soon as you run the command xhosts +some.remote.server, anyone on the remote server can connect and communicate with the display manager/x server on the host which issued the xhost command. for this reason, xhosts is considered to be an insecure access method. The preferred access method these days is xauth, which uses individual "magic cookies" to control access to an X display. With xauth, when you start your X session, you are assigned a unique cookie. If you want to run a remote X app and have it display in your local X session, you have to copy the magic cookie to the remote system and put it in your remote .Xauthority file. Only users on the remote system which have access to your magic cookie are able to access your local X session. It is worth noting that ssh has made all of this much simpler. If you enable X11 forwarding in your ssh configuration, when you connect to the remote host, ssh sets up a type of X11 forward proxy. It will do the necessary xauth merging, assign you a DISPLAY which references a local X proxy and all X requests will be automagically forwarded - you don't have to worry about performing the necessary xauth merging.

All of this generally works very nicely. However, you can have problems when you want to manipulate graphics oriented applications on a system which is not running an X server. This is because the libraries which handle things like graphic resolution, colour depths, image mapping etc all need the low level routines and information generally provided by the X server. Under MS Windows, you don't have this problem, because all of this is always available as the windowing and graphics of the environment are a part of the operating system itself and always avaialble. Under unix, this is not the case - you don't have to have an X server running.

With 9IAS and the forms server, this is a problem because it needs the low level information and routines provided by an X server in order to manipulate graphics, fonts etc. Therefore, forms6i must have access to an X server to do its work. There are three possible solutions to this problem.

1. run an X server on the host where 9IAS is installed
2. Provide access to an X server on a remote system
3. Run a "virtual" X server on the host where 9IAS is installed

Often, you don't want to run an X server on the 9IAS server as it is purely a server and is running headless - no monitor, no graphics card etc. You then have two choices, provide access to a remote X server or use a virtual server. Providing access to a remote server is usually easy to setup. Either you can use xhosts (keeping in mind security issues of course) or you can setup xauth. the problem with xauth is that valid cookies change after logins, reboots etc. The main problem with using a remote server is that you introduce an additional failure point. If network communications between the two hosts are lost, forms6i will fail, if the remote host crashes, forms will fail - essentially, your forms environment now depends on the remote host.

As we genearlly don't want to introduce additional failure points if possible, the third alternative of a virtual X server is often preferred. The virtual server essentially "fakes" a display. Generally, it reserves a buffer which represents a virtual screen and uses that screen to do "virtual" rendering for X protocol requests and return information regarding the display such as colour depth and resolution - the X libs are unaware the display is only virtual and proceed as if it was a real display.

The odd thing I don't understand about forms6i is that we needed to run both a virtual X server AND an X window manager to get it to work. Most other X apps I can run with a virtual X server without needing a window manager, but for forms6i, we needed the window manager to get it to work. Normally, X apps are totally unaware of the window manager (which is partially the reason why we can have so many different window managers with different capabilities under X) and I don't understand why forms6i needs it.

so, in summary, yes the paradigm of X windows does sort of reverse the normal client server relationship - with X windows, the applications you run are the clients of the X server. With 9IAS and the forms6i server, you need access to an X server so that forms can use some of the X library and X server information it needs to manipulate colour depths, resolutions, fonts etc when rendering the output sent to clients. This is not required under a MS Windows environment as the information and low level graphics routines ar always available as part of the operating system. One solution under Unix is to use a virtual X server which avoids having to install video hardware and the overhead of a real X server, but you do still need to run a window manager.

HTH Tim

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!