The Architecture of X-Window

(italian version)

This article want to explain what is the X-Window client/server architecture and how take advantage to it.
Attention: the correct term is X-Window and not X-Windows!! (without final "s")
It will not be my scope to teach how to program for X-Window but to understand its structure.
What is a client/server architecture? It is separate programs that talk together for a specific aim. Server will be the program that supplies the services and the client is who make requests. Generally a server it satisfies the requests from many client, but also a client can ask services from more servers.
X-Window is a protocol based on TCP/IP stack which is used between XClient and XServer to communicate. XServer job is to receive requests from XClient as: "draw line from point to point", "draw rectangle from points to points", etc. so it sent to the device driver that it will trasform them to "hardware" codes for specific video card. XServer moreover has duty to manage input from keyboard and mouse, and transmits it to the XClient to process it.
XClient job is to build the window, from borders to contents: push-buttons, menù, list-box, combo-box, etc. and sent them throw XLib function-base to XServer that it show them on monitor.
Explained XClient and XServer jobs it's easy to understand that is not necessary they run on the same machine, but through X-Window protocol that is based on the TCP/IP it's very simple to connect XClient and XServer on a geographic network (internet) or a simple local network (lan).



Architecture of X-Window


Advantages are enormous because we can use heterogenous hardware and software to execute our application, for example: we have a xclient that needs a lot of power calc, but also show complex graphs, then we can execute xclient on a Cray and the xserver in a Silicon Graphics or PC, therefore the first one offers an enormous power to us of calculation while seconds has a good support video display.
XFree86 is a free XServer implementation of X protocol on Linux (originally 86 was for Intel/compatible x86), exist however other implementations like Accelerated X and MetroX that are commercial. Also on MS-Windows and MaOS we can find some implementations of XServer that work like a normal application, but difficultly catch up the similar efficiency of XFree86.
The monolitic systems as MS-Windows and MaOS only have high performances when the relative applications are written for the interface supplied with the operating system, which often has approached directed hardware in order to to optimize the visualization to video, but achieves a serious loss of emergency in how much the device driver come executed on ring 0, to flank of the kernel, therefore if it fails the device driver it fails also the kernel with crash of the system.


Architecture of the MS-Windows systems (similarly to MaOS)


The gravity of the protocol to times is made to feel, especially on geographic networks inasmuch as the messages between client and server are frequent and often fats. We see some number: a demand from client to server is for 4 byte and the answer will be of (n*4) byte with n>7 therefore at least 32 byte finally an event from mouse or keyboard generates a message from server to client of 32 byte. You only think next to the movement of the mouse on a window that to every minimum movement generates a message of 32 byte.
That renders the dialogue between client unthinkable and server on analog telephone line.


We deepen hour the architecture side client and see therefore Window Manager, WidgetSet, Desktop Environment, XLib.
In the systems as MS-Windows and MaOS exist only one " look ", while X-Window leaves full freedom of implementazione to pact obviously to respect the rules of the protocol X. These interchanging elements mainly is 3: Window Manager, Widget Set (or toolkit) and Desktop Environment.
The more important are the first two and hour we go to analyze them more to fund.
When protocol X receives one demand to create a window request to the Window Manager, that it is in execution like xclient, the creation and design of the edge, the management of the movement, reorganization, reduction to icona and management on desktop multiple.
The WidgetSet is a bookcase connected statically or dynamically to the client and supplies a series of widget (push-buttons, lists, menu...) inserting to the inside of the window, to times can find also entire ready windows of dialogue for the use, included in these toolkit. The widget they are one composing fundamental of the aspect in the client. Since various implementazioni of widget set exist are easy to use applications with various aspects one from the other: in the shape of the menù, the push-buttons; creating therefore an atmosphere much heterogenous one.
In an application client the aspect of the edge is interchanging in chosen base to the window manager, while the content of the window that depends on the bookcase of widget is fixed and it is not modifiable if not rewriting all the code of the interface.
Some bookcases manage the aspect with of the " topics " conferring to the set of widget aspect to various times also much.
The Desktop Environments is risen of rules and instruments that make from collante between the applications (like OLE/COM/DDE... in MS-Windows).
In synthesis the CPU that executes the xclient will not owe necessarily to execute a window manager, but it will owe farces loaded to process the bookcases of widget in order to creating all the content of the window beyond obviously answering to the events and elaborarli in order to then to finish all with the shipment of the datas to the XServer.
But as they come you send the information to the XServer from the client? Through the XLib. The XLib is introduced as of the functions and in their inside they make transmissions of messages alone the XServer. In practical if we call a XLib function type draw_line_from_to this in its inside it will not go to design the line on the screen, but it will ship a message to the XServer, tramite X-Window, which recognized the datas receipts it will effectively go to design the line.
In truth the XLib is strongly of low level (much more low of the BEES than MS-Windows) and is for that the toolkit/WidgetSet are used that they work to a higher level.
In effects the XLib only serves for comfort, in order to not to owe to write code to level of TCP/IP, but the XClient applications remain to the base of all.


Examples


X-Server: XFree86, Accelerated X, MetroX.

Window Manager: AfterStep, BlackBox, WindowMaker, Fwmv95, NextStep, Ice, Enlightenment, DE(Unix), KDE(Linux).

Widget Set (toolkit): gtk+, qt, Motif(Unix), Lesstif(Linux).

Desktop Environment: Gnome, Cde, Kde, Xfce.



Various examples of XClient with Window Manager and WidgetSet Athena:
Output of the single XClient
Output of XClient + Window Manager (KDE)
Output of XClient + Window Manager (Sawmill)
Output of XClient + Window Manager (WindowMaker)




Examples of XClient developed with WigetSet Gtk+ in various themes:
Theme Aqua
Theme Metal
Theme Pixmap






Experiment


In a generalized manner when you launch startx, you launch a script that it is taken care launch the XServer and Window Manager beyond to the system for the authentications. Till now I have not never spoken about the system for the authentication that exists and very is made. In order to ago work our experiments we would owe obviously autenticate pressed the xserver in order to to visualize our windows on the video.
A simple system much and SURE one are that one to use sure shell (ssh) with parameter - X (to times are implicit in the configuration), connect to the machine with elevated calculation power and launch i client x as if we made it from a local terminal.
With a more manual system, three passages are necessary:
1. to open a xterm and to insert in the list of the host authorized the name or the address ip in which it will come executed the xclient:
xhost +namemachine
N.B. You never do not use the command: xhost +
2. launch telnet nomemacchina, autenticate etc...
3. to setting the variable DISPLAY with the name of the machine where it is in execution the xserver:
(Csh) setenv DISPLAY namemachine_with_xserver:num_display.num_monitor
(Bash) export DISPLAY=namemachine_with_xserver:num_display.num_monitor
The number display indicates in which display it will come generally shipped output (the 0), while the number monitor comes only used in the cases is more monitor, in the case than an only monitor it can be omitted.
To this point it is possible launch a whichever command: es. xlogo and we will see to appear the window of the xlogo on monitor while it is in execution in remote.

Point (3) can also be omitted, but we would owe to add to all the commands who we will launch the parameter: --display namemachine_xserver:name_display

The example of the xlogo is same absurd, but you try to think about being able to execute of the client on a various architecture from that one of the xserver, even to 64 bit.
As an example if you quite have various machines intel (economic) to 32 bit with good graphical card and a Digital Alpha or a Sun UltraSparc or IBM mainframe, because not to take advantage of these enormous powers of calculation also from more customers.
If you have a single machine you can however take advantage of the X-Window protocol, thanks also to the property multiuser of Unix and therefore to execute xclient from various customers on the same one " desktop ". Usually to connect to you like customer in order to to use X, but to one sure point you have the necessity launch an application with the rights of root... and nothing easier: you open a xterm you launch
ssh -X -l root localhost
and you are ready launch the xclient!





Observations and comments are very chip axes.
The author,Filippo Maguolo.