|
|
X Windows operates over TCP, typically using server port numbers starting with 6000. The X server for a system's first display listens on port 6000; if the system has a second display, its server listens on port 6001; a third display would listen on 6002; etc. The protocol used over this reliable stream connection is essentially request/reply, and it's reputation is as a fat protocol that consumes a lot of bandwidth. Lightweight X (LWX), introduced in X11R6, attempts to reduces X's bandwidth needs to the point where it can be run over dialup modem connections.
The X Protocol, documented in a postscript file, defines dozens of messages that can be exchanged between a client and a server. They can generally be classified into four categories: Requests, Replies, Events, and Errors. Typical requests include Draw PolyLine, Draw Text, Create Window, Fill. Replies are matched to particular Requests. Events are asynchronous occurances such as keystrokes and mouse clicks. Errors are matched to particular Requests.
If a window is partially or fully obscured by another, overlapping window, the server has two options available to it. The server can allocate additional memory, called backing store, to record to contents of the obscured window. This is purely optional, however. The server can simply ignore the obscured part of the window. Later, when that part of the window becomes visible again, the server sends an Expose event to the client, which must then redraw the affected area. The client, therefore, must be prepared to redraw any part of its windows at any time.
Applications do not need to access the X Windows protocol directly. X Windows supports several APIs. The most basic of these is Xlib, which interfaces fairly directly to the underlying network protocol. Most X client applications are linked against Xlib, which allows them to operate on either a local or remote X server, simply by adjusting either an environment variable or a command-line argument.
Widgets layer on top of Xlib and provide X Windows with an object-oriented programming model. A widget is an X window capable of handling most of its own protocol interaction. The most popular widget sets are Athena Widgets (aw) and Motif.
X Window's security model is all-or-nothing. Either an application can perform any operation on an X desktop, or it can perform none. There is no concept of limiting an application to a single top-level window, for example. Although there is power in this model, such as allowing the window manager to be a normal X client, there are also serious performance implications. A hostile X client could connect to an X server and arrange to capture any screen image, or even to capture keystrokes as a password is being typing in one of the windows. For this reasons, X servers are typically fairly restrictive about which clients they will accept connections from. Two major security models are available. Host-based security (traditionally controlled by the xhost program), permits or denies connections based on their source IP addresses. Authentication (traditionally controlled by the xauth program), requires the connecting program to possess a secret password, typically stored in a UNIX file and subject to standard UNIX access controls. Kerberos-based authentication is also available.