diff options
Diffstat (limited to 'xlib-tutorial/server.html')
| -rw-r--r-- | xlib-tutorial/server.html | 89 |
1 files changed, 0 insertions, 89 deletions
diff --git a/xlib-tutorial/server.html b/xlib-tutorial/server.html deleted file mode 100644 index a408834..0000000 --- a/xlib-tutorial/server.html +++ /dev/null | |||
| @@ -1,89 +0,0 @@ | |||
| 1 | <HTML> | ||
| 2 | <HEAD> | ||
| 3 | <TITLE>Xlib programming tutorial: What is all this "client-server" stuff ?</TITLE> | ||
| 4 | </HEAD> | ||
| 5 | |||
| 6 | <BODY> | ||
| 7 | <H1 ALIGN=center>What does all this stuff about "client-server" mean ?</H1> | ||
| 8 | |||
| 9 | Everybody says that X has a "client-server" architecture. So this must | ||
| 10 | be true, but what does it mean ? | ||
| 11 | |||
| 12 | <P> | ||
| 13 | |||
| 14 | Well, basically a client-server architecture is conceptually a simple | ||
| 15 | thing, but the consequences may be a bit subtle, especially the way it | ||
| 16 | is implemented in the Xlib. | ||
| 17 | |||
| 18 | <H2>What is a client-server architecture ?</H2> | ||
| 19 | |||
| 20 | A client-server architecture is a general mechanism for handling a | ||
| 21 | shared resource that several programs may want to access | ||
| 22 | simultaneously. In the case of X, the shared resources are the drawing | ||
| 23 | area and the input channel. If every process was allowed to write on | ||
| 24 | it at its will, several processes may want to draw at the same place, | ||
| 25 | resulting in an unpredictable chaos. Thus, only one process is allowed | ||
| 26 | to get access to the drawing area: the X server. The processes wanting | ||
| 27 | to draw stuff or get inputs send requests to the X servers (they are | ||
| 28 | "clients"). They do this over a communication channel. The X server | ||
| 29 | performs the requests for its clients, and sends them back replies. It | ||
| 30 | may also send messages without explicit client's requests to keep them | ||
| 31 | informed of what is going on. These messages sent by the server on its | ||
| 32 | own behalf are called "events". | ||
| 33 | |||
| 34 | <H2>Advantages of the client-server architecture</H2> | ||
| 35 | |||
| 36 | The client-server architecture has several advantages, many of them | ||
| 37 | resulting from the ability to run the server and the clients on | ||
| 38 | separate machines. Here are some advantages: | ||
| 39 | |||
| 40 | <UL> | ||
| 41 | |||
| 42 | <LI> A client-server architectured system can be very robust: since | ||
| 43 | the server runs in its own address space, it can protect itself | ||
| 44 | against poorly written clients. Thus, if a client has a bug, it | ||
| 45 | will crash alone, the server and the other clients still running | ||
| 46 | as if nothing has happened. | ||
| 47 | |||
| 48 | <LI> The client and the server don't have to run on the same machine, | ||
| 49 | so we have some communication mechanism here. | ||
| 50 | |||
| 51 | <LI> The client and the server may run on separate machines, resulting | ||
| 52 | in a better load distribution (possibly). | ||
| 53 | |||
| 54 | <LI> The client and the server don't have to run on the same hardware, | ||
| 55 | operating system, etc., giving a better interoperability. | ||
| 56 | |||
| 57 | </UL> | ||
| 58 | |||
| 59 | <H2>Structure of the X client-server architecture</H2> | ||
| 60 | |||
| 61 | As we already mentioned, the server and a client communicates over a | ||
| 62 | communication channel. This channel is composed of two layers: the | ||
| 63 | low-level one, which is responsible for carrying bytes in a reliable | ||
| 64 | way (that is with no loss nor duplication). This link may be among | ||
| 65 | others a named pipe in the Unix environment, a DECNet link and of | ||
| 66 | course a TCP/IP connection. | ||
| 67 | |||
| 68 | <P> | ||
| 69 | |||
| 70 | The upper layer use the byte-transport channel to implement a | ||
| 71 | higher-level protocol: the X protocol. This protocol says how to tell | ||
| 72 | the server to request window creation, graphics drawing, and so on, | ||
| 73 | and how the server answers and sends events. The protocol itself is | ||
| 74 | separated into different parts: | ||
| 75 | |||
| 76 | <UL> | ||
| 77 | |||
| 78 | <LI> How to connect and how to break a connection, | ||
| 79 | <LI> how to represent the different data types, | ||
| 80 | <LI> what are the requests and what they mean and | ||
| 81 | <LI> what are the replies and what they mean. | ||
| 82 | |||
| 83 | </UL> | ||
| 84 | |||
| 85 | [to be continued]. | ||
| 86 | |||
| 87 | <HR><ADDRESS><A HREF="http://tronche.com/">Christophe Tronche</A>, <A HREF="mailto:ch.tronche@computer.org">ch.tronche@computer.org</A></ADDRESS> | ||
| 88 | </BODY> | ||
| 89 | </HTML> | ||