Communication between the Server and Clients
This chapter deals with the second major component of the system - the communication chanuel between the elient and server, and what passes accoss it. First we look in detail at the requests the clients send to the server, the events the server sends back to the cfients, and how these are used to handle user input. Then we go on to look at features of the network itself, how heavily it is loaded, and how special systems can cope with very slow network links.
The only way a client can perform any graphics or window operation is by sending the appropriate requests to the server. You can think of requests as the interface between client and server, or as the equivalent of `system calls' provided by an operating system.
We have already dealt with events relating to graphics and text drawing in Modules 3.3.2 and 3.5. X provides many other requests to let clients manage windows and other resources. These are some of the classes of request available:
Even if you are programming the system, you don't ever have to deal with requests directly; the standard X subroutine library (Xlib) insulates you from them by providing convenient functions which do all the hard work of constructing the request and passing it to the network transport software. Moreover, in the last chapter we saw the effects that requests cause - the actions that the server performs handling colours and fonts, and drawing graphics and text, etc. So we won't go into any more detail about individual requests, but there are some general characteristics of requests that need to be emphasized. In the rest of this module we see that requests are relatively high-level, and in the next module we look at how they are communicated.
This means that requests are network efficient - they use little network bandwidth, and the number of pixels affected by a request is typically 10 or 100 times greater than the number of bits comprising the request. As an example, a text request to draw a string (`the quick brown fox jumps over a lazy dog') is shown in Figure A: the string consists of 41 characters, and the total number of bytes in the request is 60, so the request is not much bigger than the absolute minimum possible.
Later on in this chapter (Module 4.5) and again in Module 13.2 we'll see that the load X imposes on the network is less than you might expect.
To maximize throughput, requests are sent asynchronously - in general, the server does not reply to the client to requests have arrived. This makes good use of the available network capacity and allows high throughput.
The client transmits almost all requests to the server asynchronously, and the server does not acknowledge that it has received the request. So after the client sends one request it doesn't have to wait for a reply but can send the next request immediately. When you are writing a program, this means that those functions in the standard X subroutine library (Xlib), which cause requests to be sent, return immediately and don't `block', that is, they don't wait to receive until they receive a return value. This contrasts with an Open File system call, which waits until the operating system has replied whether the file has been opened successfully or not, and then it returns this status to the calling program. Figure A shows how three requests are sent asynchronously with no time gap between them.
The effect of this is good utilization of network bandwidth. Because the client can push requests `down the wire' as quickly as it can generate them, it means there are no occasions when the network is standing idle because the client is awaiting a response from the server. Further, the network transport layer can package many requests into a single network packet, which reduces network overhead.
The reason that a reply from the server is unnecessary is that X works over a reliable stream network connection; the transport that X uses guarantees that the bytes sent from the client amve correctly at the server. This is also how X can be network independent - it relies on the lower layers to deal with the networking problems, so no network-specific handling needs to be incorporated in the system.
Asynchronous operation is necessary to make displaying over a network feasible. If request transmission were synchronous, the client would have to wait for a reply from the server each time it sent a request. The wait time would be:
that is, the time for a round-trip. As shown in Figure B, the time to send three requests synchronously involves three round-trip times. Even on fast networks this could easily be many tens of milliseconds and therefore that less than a hundred requests a second could be sent. This in turn would mean that just scrolling the text in a window would only ever be as fast as over a 9600 bps terminal line! (X's predecessor, the W window system, was synchronous. It worked acceptably on the networks it was developed for, but over standard networks it proved too slow to be usable.)time to travel from client to server +
time for server to process request +
time to travel from server back to client
(One disadvantage of asynchronous operation is that if an error does occur on the server due to your application, it is not easy to work out which request caused the error, as many requests may have been sent since. This complicates debugging. There is no easy answer to this, but using standard toolkits goes a long way to help. You can also explicitly force X to operate synchronously, to aid debugging.)
Surprisingly, the performance of the network is rarely the limiting factor in the overall system. In fact, the overall performance of an X application is sometimes better when working remotely over a network than when running locally on the same CPU as the server. Simply, this is because in the remote case you have two CPUs sharing the work in parallel, they are not contending for resources and they are not causing each other to page or swap in and out of memory. (We examine network performance in more detail in Modules 4.5 and 13.2.)
Typically these requests ask for information from the server about itself or some of its resources. Such requests include querying whether something is available (a font, a server extension) are supported, asking for details of something (window attributes, the value of a property, size characteristics of a font, etc.) or listing items (properties on a window, available fonts, hosts allowed connect to the server, etc.).
Because round trips can take a considerable time (Figure B), for good performance you obviously want to minimize the number of requests in your program causing round trips. We discuss this further in Module I3.3.
So far we have looked at how the client requests the server to perform actions such as drawing graphics or creating a window - essentially how a client gets output onto the screen. Now we are looking at how input is handled using events, and also how the server uses events to inform applications about other changes they are interested in, exposure events for example. In a way, you can think of events as the reverse of requests - events are the information sent back from the server to the client (Figure A).
Apart from input from the keyboard and mouse, events are generated in a window when the configuration (size or position) of any of its sub-windows changes, when subwindows are created or destroyed, or mapped or unmapped. When several applications are running, events are also required to tell one client when another has installed or deinstalled a colormap, or when the keyboard mapping (which we discuss in the module after next) has changed. Other events inform a client when the contents of a property has changed and, as we shall see in Module 9.3, this enables clients to exchange information with each other. The selections mechanism of Module 9.4 also uses events for inter-client communication.
In the rest of this module we look at how events in general work, and in the following modules we examine keyboard input events in detail.
Normally, events are relatively infrequent because most events relate to user input, and people only type at a few characters per second. It is only where the motion of the mouse is being tracked in detail - for example, in freehand drawing applications, or when `rubber-banding' a window during a resize operation - will there be a much higher rate of events, perhaps 50-150 per second.
To minimize the load of processing events, the client has to specify explicitly to the server the types of events it wants to be informed of, and in which windows. The server will send only these specific events to the client, so the client won't waste time processing events that are not relevant to it. Different sets of events of interest can be specified for each separate window in your application. For example, a client will want to process Any events that are not requested by some application are thrown away; for example, many applications ignore the It is possible for several clients to request the same event on the same window: each of them will be informed when such an event occurs.
All events specify what type of event they are and in which window they occurred. Beyond that, the detailed contents of the event vary with the type of event, reasonably enough. For example, a The types of event generated by mouse input are as follows: Figure B shows the detailed contents of an event caused by dragging with the middle mouse button (button no. 2).
When the key is released, a Just like other events, In the next module we look in more detail at how a meaning is attached to these keyboard events.
(If technical details aren 't so relevant to you, you can skip over this module.)
When the keyboard event arrives, how does the client know what it is supposed to mean, as it contains little other than a key number? First, let's consider the simplest case, in which the key is to be interpreted as an ASCII character. The server does in fact contain a table saying which symbols are painted on the caps of each key; these symbols are called keysyms. So the table is a mapping of keycodes to keysyms. On some systems the table is obtained from the hardware or operating system. On others it has to be built manually by the server developer, and is compiled into the server, or is supplied as a configuration file which is read by the server every time it starts up. (In this way if a different keyboard type is to be used, only the configuration file needs to be changed to ensure correct keycode/keysym handling.) Taking our keyboard as an example, on the third row we have the keys marked with Control, A, S, ... , and on the numeric keypad a 4 with a left arrow, then a 5, then a 6 with a right arrow, and finally a plus sign. The server table entries for these keys are:
(The keysym-2 entry relates more or less to the key when Shifted.) When the client starts, it can request this table from the server, and then use it to map the keycodes onto whatever characters are desired. For example, if ASCII characters are required, for the alphabetic keysyms like A and S the client only has to generate the directly corresponding character, checking the state of the modifier keys (Ctrl, Shift, etc.) to see if the character is to be lowercase, uppercase, or a control character. In fact there is a special function in Xlib specially for this (Figure A). Other keysyms such as the cursor keys (Left and Right) and function keys (F31) are interpreted in a client-specific way; for example, our terminal emulator program maps Right onto the 3- character sequence Escape [ n, whereas in our text editor it is interpreted as the single character ctl-F. Later on, in Module 12.1, we'll see how on the client side we can change our keyboard mapping on a per-application basis (or even per window within the application), using the translations mechanism of the standard X toolkit.
Other, more elaborate ways to interpret the keys are possible. For example, if a client is using a Japanese character set, it may be necessary for the user to press several keys in succession to specify one Kanji character to be input. It is precisely because different applications may want to use different character sets that the character interpretation is left to the client. An extreme example of this would be a translator's workstation, which might have one window in Japanese, another in Hebrew, a third using English in ASCII encoding, and another English window connected to an IBM computer which is expecting EBCDIC characters.
A common problem, especially on PCs where people often swap the physical keyboard, is that the server table doesn't match the physical keyboard. Then the client generates characters according to what the server believes is written on the key caps, not what is actually on them, so you get confusing results. Fortunately, you can print the server table and modify it (using the MIT program xmodmap), so customizing the server to match the keyboard you have. People often use this facility even when the keyboard mapping is correct, to `rearrange' the keyboard to their particular preference, for example, to alter the location of the Control and Shift keys on a PC keyboard to match those on a workstation. And as we mentioned above, some servers let you install a different mapping table just by using a different keyboard configuration file.
In the next module we look at `input methods', which are a more sophisticated way of converting server events into the characters required by the application.
Release 5 extends and simplifies the support of multiple languages, by means of the input method mechanism. An input method is an algorithm or mechanism for entering characters other than those on the keyboard. This is necessary for European languages which contain characters other than ASCII, and for oriental languages which contain far more characters than could be accommodated directly on any keyboard. Entering special symbols by using a compose key is an example of an input method implemented on many hardware terminals. The input method effectively translates events from the server into characters in the particular language which the application requires (Figure A).
X allows input methods to be implemented either in the client as part of a library (Figure B), or as a separate process known as an input server (Figure C). In either case, keyboard events are received by the input method and processed, and the resulting decoded character is passed to the application program. The advantage of the separate process approach is that a single server can handle many applications on several different machines on the network, although there is a communications overhead. Incorporating the input method in the library compiled into the program removes the communication load, but at the cost of reduced flexibility - the program can no longer select its input method dynamically, which it must if it is to be portable to different language environments.
Multi-language support and internationalization are covered further in Module 5.3. The next module looks at a mechanism similar in a way to input methods, where special processing of input is handled by a separate process.
The simplest type of processing involves a process that sits between client and server. To the X server it is just a client, whereas to the user application it appears to be an X server and it is to this process that the initial connection is made (Figure A). The process notes all events and requests, but otherwise passes them through transparently, so the client and real X server continue to work, and require no alteration. The intercepting process can record or print out details of the events and requests. (See Module 13.4.1 for examples of how this type of facility is used.)
XTrap was developed to allow X sessions to be recorded and played back, and for testing and performance measurements. However, it has also been used to allow people with manual disabilities to use the X system. Much X software implicitly assumes that there is a pointing device such as a mouse or trackball on the system, and that the user can use both the pointer and the keyboard simultaneously; for the manually disabled, this may not be true. The solution using XTrap overcomes this by providing emulations for the mouse functions, and allowing one-at-a-time key presses to simulate the use of modifier keys and chords; for example, it allows the modifier keys Control and Alt to be locked, to supplement the standard CapsLock provided by the keyboard. But the XTrap control application goes far beyond providing simplistic emulation of mouse functions (vertical/horizontal movement, button-clicks, etc.); it can provide an end-user of standard, unmodified, X applications with higher-level replacements of the logical or semantic functions the mouse is used for. For example, it can be set up so that a single key-press ean position the pointer in a particular pushbutton within a previously specified application's window; the user doesn't have to move the pointer up and across to the correct position by repeatedly and tediously pressing some keyboard keys emulating mouse motion.
XTrap is included in the user-contributed software of the MI'T Release.
In the next module we look at another system that intercepts events and requests and modifies them, but does it entirely within an `ordinary' client and without any modifications to the server.
(If technical details aren't so relevant to you, you can skip over this module.)
The system we describe here is not available commercially nor is it included in the MIT Release; however, we cover it in some detail not only because it offers a very useful facility, but also because it illustrates the extent to which separating the client and the server allows X to be enhanced without any changes to the server or the Protocol.
Virtual Screen is a client program that provides a virtual screen or virtual root window on which other windows can exist. The virtual root window is just a normal X window on the real X display. To the applications using it, the Virtual Screen program appears to be an X display, but to the real X server it is just another client; so to operate, it requires no modification to the real X server. Like some of the systems we mentioned in the previous module, it is a special client which sits between the normal applications and the X server (Figure A).
However, requests from the applications are not necessarily passed through unchanged. In particular, any requests that refer to the real root window, of the real X server, are modified to refer to the virtual root window provided by Virtual Screen. Thus the system overall is more precisely illustrated by Figure B.
Virtual Screen has been used for two quite different purposes. The first is as a general mechanism for creating multimedia documents. Let's consider a multimedia editor as an example. The basic editor handles text in the normal way. To include a drawing in the document being edited, a Virtual Screen is incorporated into the editor's window (the user presses an insert button to do this), and the user's favourite X drawing application is run displaying its X window onto this Virtual Screen root window. Editing the drawing is performed using the drawing application and in the normal way, except that the drawing area is encapsulated in the editor. Similarly, other types of media such as spreadsheets, video, and animated displays, can be incorporated in the document by running their appropriate applications in an included Virtual SCreen.
The other application of Virtual Screen has been to provide the user with `task management'. You can dedicate a separate Virtual Screen to each major activity you perform, and group all the applications you need to perform that task onto the Virtual Screen. For example, for preparing a financial report, you might have a spreadsheet, a calculator, and a word processor, whereas for programming you might use a couple of editors, a debugger, and the application you are developing. When you are not doing a task, you can just iconify its Virtual Screen (which as we said is really just a normal X window) to keep it from cluttering your screen. Each Virtual Screen can even have its own window manager handling the windows on it, so you can manage the windows within a Virtual Screen just like you do on a real screen! (By contrast, in the multimedia case, each Virtual SCreen has only one application connected to it and window management within the screen is therefore not required.)
X does not use facilities specific to particular networking systems, and so it can operate over many different ones: it is network independent. X assumes that the complexities of networking - ensuring reliable delivery of data, acknowledging receipt, checksumming to validate contents of packets, re-sending lost packets, etc. - are all handled by the lower (network) layers of the system, so X itself doesn't have to bother with them. As a result, X does not contain code to handle those aspects, which simplifies its implementation, and isolates it from specific system dependencies. This layering approach is illustrated in Figure A.
X is able to use all these different systems because its networking requirements are fairly simple; it needs a reliable stream protocol. Here, `reliable' is a strict term: it means that bytes sent across the network are guaranteed to amve at the other end, and are guaranteed to arnve in the order they were sent. This is why X can operate asynchronously, as we described in Module 4.1- it knows that once it passes requests or events to the network, they will reach the other end.
X prefers a `stream' connection to a record-oriented one because X can then buffer things more efficiently. As the X loading increases, it can send progressively larger packets, with consequently less overhead. This is a sensible way to operate; be efficient when the load is heavy, but when you are lightly loaded you can afford to waste a few cycles.
In order to support both local and remote operation, X obviously must operate over both types of communication system. In fact, X works over true inter-machine networking systems, such as TCP/IP, DECnet, AppIeTalk, and OSI (all of which offer reliable byte streams) and inter-process communication systems (IPCs) for communication within a single machine, such as UNIX sockets, shared memory, streams, and named pipes.
Considering the lower networking levels, it follows that X operates over any of the physical systems supported by the high-level protocols such as TCP/IP or DECnet. For example, X is widely used across Ethernet, token ring, FDDI and X.25 networks. X can also be run over modem-eonnected serial lines, for instance using TCP/IP in the form of SLIP (serial line Internet Protocol) or PPP (point-to-point protocol). When ISDN becomes widely available as a service, it will be an attractive option for connecting widely spread X stations to central computing resources, such as allowing people to use their office X applications from workstations at home. (However, ISDN is only a fast digital replacement for a modem connection, so you will still have to use a network protocol like SLIP across these links.)
To avoid confusion, it is worth pointing out that a client and server can operate across a particular network system, OSI say, only if both of them have had support for it compiled into them when they were written. In other words, X of itself does not provide any new support for any type of networking system; however, X systems can be written to use any networking support that has already been developed. Thus the network transport system used by your server determines which of the machines on your network you can interoperate with, that is, run clients on. For example, if you have an OSI-only server, you won't be able to use applications running on a TCP/IP- based remote host. However there are X servers that have been written to handle more than one protocol simultaneously, for instance both TCP/IP and DECnet as shown in Figure B. Here, cutting-and-pasting from application T's window to application D's is really transfernng data from a VMS VAX across DECnet and X.25 to a UNIX machine across TCP/IP and Ethernet, using the X server as an intermediary.
When X was designed the type of networks then current on university campuses and within organizations were Ethernet or token ring. It was developed with these in mind
- its performance on these everyday types of networks had to be acceptable. Performance studies show that for a typical mixed workload, an X-terminal (which is the worst case, as all its clients run over the network) peaks at about 1 % of an Ethernet; because not all the terminals peak simultaneously, a single Ethernet segment should be able to handle hundreds of X-terminals (according to the X-terminal manufacturers). Other measurements, relating to implementing X over OSI transports, indicate an average bandwidth requirement of only about 20 kbits per second, that is, about 0.2% of an Ethernet.
Figure A shows network loadings for some common activities. It is clear that activities such as rubber-banding window outlines and tracking the mouse, which are commonly thought to be very consumptive, impose relatively little load. But the figure does show that some activities do cause a heavy load. Not surprisingly, dumping the contents of a window - which involves manipulating and transmitting each pixel individually rather than sending just high-level object-based requests - imposes the heaviest burden.
There are some data-intensive applications that are just not suitable for running remotely, and which need to be run on a workstation where the server and client are on the same CPU. Typically these involve images, which have to be specified and manipulated on a pixel-by-pixel basis; this involves transmission of large quantities of data between client and server.
But in normal situations the network is not the limiting factor on performance for remote applications. The limiting factor is often the display hardware - even over the network clients can send requests quicker than the hardware can process them. This is not surprising, considering that requests can be sent asynchronously, that they are high-level and network-efficient, and that the server is not competing with the client for the use of the client's CPU. For similar reasons 9.6 or 19.2 kbits per second phone lines (often used by people working from home) have proven usable. This is especially true for applications which are largely text-based: as we discussed in Module 4.1, the overhead added by X to text transmission is quite small. (Module 13.2.1 deals with how performance over slow network connections is being improved.)
The second aspect of network speed is the latency - how long is it before the first bit sent actually arrives at its destination? A long latency will affect the interactxve performance of a system. For example, if latency is a quarter of a second, when you press a key on the server, the keyboard event takes 0.25 s to travel to the client, the client responds with a request to draw a character on the screen, and that request takes another 0.25 s to return to the server. This means that you have to wait an absolute minimum of half a second for the first character you type to be echoed. If you were tracking the mouse, for example when drawing freehand, or rubber-banding a window, this latency would be very uncomfortable.
Latency and bandwidth are completely separate. A serial line using copper wires may only have a 19.2 kbits per second bandwidth, but it has tiny latency - once sent, signals travel along the wire at about two-thirds the speed of light, that is, they arnve almost instantly. On the other hand, a satellite link has very high bandwidth, perhaps many Megabits per second, but it has a very high latency because the signal has so far to travel - from earth to the satellite and back down again - and even at the speed of light this imposes a considerable delay.
In summary, bandwidth determines how acceptably you can shift large amounts of data, paracularly for pixel-based images, whereas low lat.ency gives you a small round-trip time which is essential for good interactive feel.
(See Module 13.2 for more about network performance.)
Because the only connection between the client and the server is the communications link between them, it follows that the `messages' sent across this link are the only factor which determines whether a client will successfully inter-operate with a server. The X Protocol is the official MIT standard which determines what these messages are, the format in which they are transmitted (the encoding of the requests, replies, and events) and how the client and server are to interpet them.
In a sense, the Protocol is X - the eode from MIT is just a sample implementation of server and clients, which many people find useful. The MIT code includes the basic X programming library, Xlib, which is more or less a set of C-language `function-wrappers' around the basic protocol requests. (We discuss Xlib, and the extra functionality it provides, in Module 5.2.2.)
Figure A shows a history of X version numbers. X went from version 1 to 9 very quickly - in the early days many backward-incompatible changes were made to it as it developed. Version 10 was widely used, and a few commercial products were based on it, but is was not until X version 11 ( `X 11 ' ) that X became very widely accepted and large-scale commercial product development began. So much has now been invested in X11 that a version 12 is unthinkable - X12 would require just too much redevelopment of existing software.
However, the fact that the Protocol is fixed does not mean that the functionality of the system is frozen. Obviously new clients can be written, but by means of the extension mechanism designed into X11 from the beginning, new features can be added to the system in a controlled way (see Module 3.8). It is also worth noting that many major improvements to X, such as the Xcms colour management system, input methods, and improved internationalization support, are entirely on the client side. And even other features such as the font server and xdm and XDMCP (Module 11.1) which do affect the X server's operation, only relate to its system administration and don't affect how requests are processed. (We cover this issue in more detail in the next mcdule.)
MIT releases typically occur about every 12-18 months. Commercial suppliers often lag about 12 months behind.
In the next module we see how version and release numbers affect compatibility of clients with servers.
How, if the X Protocol is now frozen at version 11, can XI 1 clients be incompatible with earlier or later servers? What do manufacturer's claims like `Fully conformant to Release 5 of X I I ' mean?
For development systems, and for software packages that include client programs, conforming to a release means providing all the updated library facilities, plus at least the new client programs essential to using new system administration features. Ideally all the other new and modified MIT clients would be included, but as many manufacturers have provided their own replacements for various applications such as terminal emulator, clock, editor, etc., these may be omitted. (After Release 5, it is likely that many of the standard MIT will no longer be part of the core release, but will be included as part of the contrib software instead, emphasizing that the MTT Release is just a sample.)
In practice, manufacturers must continually track the features of the latest MIT releases if they are to remain competitive, because the new features are so important to users and system managers.
Compatibility ofclients between releases is not usually a problem, because what they are sending to and receiving from the server is determined by the X Protocol, which is unchanged. Typically, you can be using one release of the server today and switch over to a new release tomorrow without any change whatever to your applications. (This is just as well, as the new X-terminal you plug into your network may be using a later server release, and you don't want to be forced to upgrade all your applications everywhere else on the network just because you bought one new terminal.)
However, difficulties can arise with a program when you recompile it, because often the interfaces to the programming libraries used by the program change with a new release. Similarly, the internals of the libraries may have altered, so that relinking may give problems, or the final program may not work as intended. This is most common when you are using an X toolkit in your program. Toolkits are continually being enhanced, and so change relatively frequently. Even so, an existing toolkit application will continue to work OK unless you recompile it. The solution in both cases is to amend the source-code to bring it into line with the new library interface, and rebuild. You should also keep the old version of the program and the old libraries available, so that you can maintain the program based on the earlier X release, until porting to the new release is complete and has been tested. (Even if you don't recompile, you may also get problems if the original application was built using shared libraries, because these effectively involve dynamic relinking of the program every time it is run. The solution here is to keep the old shared libraries available as well as the new ones. For more about shared libraries, see Module 14.1.)
In Release 4 a bug in the server was corrected, causing stricter checking of unused data fields in certain requests. Many applications had been built which now failed; a special bc (backward compatibility) option is provided in most servers now to disable this strict checking, to allow the erroneous programs still to work.
For a server product, conforming to an MIT release is simply a matter of ensuring all the new functionality, including extensions and non-extensions, is present. While the new features may not affect the X Protocol, they can still affect either how an application works, or how you administer the system. Let's look at each case in turn.
New application functionality in a release can be included as an extension, or in some other way; we'll illustrate this with two examples. First, Release 4 introduced the SHAPE extension to allow non-rectangular windows. Servers prior to Release 4 don't include this, so if your applications insists on having non-rectangular windows, it just won't work with Release 3 servers or earlier. (See Module 3.8.1 for how applications ought to query the server to see if an extension is present.) Second, font scaling was introduced in Release 5, not as an extension, but as a change in how the XLFD name of a font is interpreted - by using the correct font name you specify that a font is to be made available at some (scaled) point-size. If your application implicitly assumes that font scaling is available and that it will therefore it dynamically request fonts at different and unusual sizes, your program is unlikely to work properly with pre-Release 5 servers. To summarize, if your application assumes and depends on functionality that was not available in earlier releases, that application will have backward-compatibility problems.
The second type of functionality included in a new release relates to system administration. These changes won't affect individual client applications but, because they affect how you manage your X network as a whole, they may actually be much more important than application-related changes. Two examples are the introduction of XDMCP in Release 4, and the font server in Release 5. With XDMCP (described in Module 11.1.3) you can add X stations very simply to your network, and manage all startup configuration information centrally instead of holding it on each individual station. Once your network management is based on this, going back to Release 3 servers that don't provide it becomes a real headache even though all your applications programs will work OK. The other example is the Release 5 font server. Not having it won't cause applications to fail, but once you configure your whole network to share and access fonts using the font server, incorporating an X server without it into your network probably costs more effort than it's really worth.
In the next chapter we look at the third component of the system - the client program - having already covered here how it handles user input.
Figure A. Events are `the opposite' of requests.
4.2.1 The information contained in an event
All events contain a common set of basic information, such as where and when the event occurred. Each particular event type also contains information specific to itself, giving more detail about the type of change in the system it relates to. For keyboard events the server only reports to the client that you have pressed or released that particular key, but the server attaches no meaning to it.
Mouse events
Keyboard input
When you press a key on the keyboard, the server generates a < KeyPress> event. The event does not interpret the meaning of thekey: instead it contains a number identifying which key has beenpressed. For example, on our workstation, the numeric identifier for the key with Control marked on it is 83, and the key marked C is 109. These numeric identifiers are called keycodes. The event also contains an indication of which modifier keys (Ctrl, Shift, etc.) were depressed at the time the key was pressed. But note that the server has not assigned any meaning to the key, for instance it has not interpreted it as an ASCll character, or an EBCDIC one, or anything else - that's done later, and it is done by the client. Figune C shows the events caused by pressing (and subsequently releasing) ctl-C.
Figure A. Menu pane highlighted, after Enter event received.
Figure B. Details of event, dragging with middle mouse-button.
Figure C. Details of events due to pressing Ctrl-C.
4.2.2 Keyboard input is received on the server but interpreted in the client
When you press or release a keyboard key it is the client that interprets the key and decides whether it means an ASCII `w', say, or a `Trademark' symbol, or some Japanese character. This permits multiple applications with different character sets to coexist on the same display at the same time.
Figure A. How keycodes are converted to characters
4.2.3 Input methods
So that you can enter characters in languages that are not adequately supported by normal (ASCII) computer keyboards, X provides `input methods'. These are algorithms for entering characters in a particular language and can be implemented within the application itself or in a separate process called an input server.
Figure A. The input method receives events and translates them into the language-specific characters for the application.
Figure B. An input method implemented as part of client libraries.
Figure C. Input method implemented as a separate process servicing many applications.
4.3 Intercepting input and requests for special handling
All user input (and requests from clients, too) can be channelled via a separate process. This can be used merely for performance testing and analysing system behaviour, or to provide special handling - for example, to allow voice input, or give disabled users facilities to manage a keyboard more easily, or emulate a mouse.
XTrap
The XTrap server extension developed by DEC intercepts events from the input devices before they are processed by the server proper, and passes them to a separate client application (Figure B). The application can perform specialized processing on them, and pass them back, perhaps modified, or with some extra events added, back to XTrap to despatch them to the server. XTrap also intercepts requests and passes them to the separate application before the X server processes them. While XTrap is a server extension, it is only the interception of events and requests that happens within the server; all special processing is handled within an external client application.
Figure A. Separate process between client and server, intercepting all X traffic.
Figure B. XTrap intercepts events and requests
4.3.1 The Virtual Screen system
The Virtual Screen system provides a `virtual root window' by intercepting requests to the X server and modifying them appropriately. Windows on this virtual screen are shown on a normal X window on the real X server. This system has been used for multi-media applications and task management.
Figure A. The VirtualScreen client between applications and server.
Figure B. VirtualScreen modifies requests before passing them to the real server.
4.4 X can work over many different network types, as well as locally
X is network independent - it can work over any network that provides guaranteed delivery of data in the order sent. Several different network systems can be used simultaneously. However in practice most X systems are TCP/IP based.
Figure A. X leaves transport between client and server to lower-down system software and hardware.
Figure B. Multi-protocol server simplifies communication between disparate operating systems and networks.
4.5 What load does X impose on the network?
Typically an X display uses a very small fraction of the bandwidth of a network with a capacity like an Ethernet, although peak loads may be 30% or more. In some circumstances dial-up phone lines can give acceptable performance. However, executing over the network is not suitable for some data-intensive applications.
Network `speed': latency versus bandwidth
There are two different aspects of network speed. The first is the obvious and most common measure of bandwidth: how many bits can you send down the wire in each second. As we mentioned above, there is a sensible lower limit of several tens of Kbits per second on this; and for some data-intensive applications, the higher the better. But for most applications, very high bandwidth is not essential.
Figure A. Peak network loads imposed by common activities.
4.6 X Version and Release numbers, and compatibility issues
The X Protocol definition - the formal description of X - has been frozen at `Version' 11. MIT distributes occasional `Releases' of implementations of the Protocol, adding functionality or improving performance.
Version numbering
The X version number refers to the Protocol. The version number is incnemented when the protocol changes, that is when the new version becomes incompatible with the earlier one, and existing programs will no longer work correctly. The current version number is ` 11 '. When we say a program `uses X11 ' or `conforms to X version 11 ', what we mean is that it is using this version of the Protocol, and that the messages being passed between client and server are in the format specified by that version.
Release numbering
Every so often, MIT issues a colleetion of sample servers, clients, and programming libraries for the current version; these are releases of X. Releases usually include:
Figure A. Summary of X version and release numbers.
4.6.1 Compatibility and conformance
Applications are forward-compatible with later releases of the server, and many are backward-compatible too. However, problems arise in applications when new `standard' extensions are used, and in system administration areas which depend on functionality available only in later releases.
Summary
This chapter has dealt with the second of the three major components of the system - the information exchanged between client and server over the communications link between them. We looked at the events sent from the server, their contents, and the format in which they are transmitted over the network. We saw that events are the mechanism for receiving input from the user, but the processing of user input is left to the client as only it can decide how input is to be interpreted, perhaps relying on input methods for sophisticated processing. Then we looked more closely at how X can operate over many different types of network, and the issues of network performance. Finally we saw that the X Protocol is the formal definition and standard of what is communicated between client and server, and saw how X's version- and release-numbers affect compatible operation of client and server.