3. X ウィンドウシステムのアーキテクチャ - その概要

X はクライアント-サーバーというアーキテクチャを使って設計された。 アプリケーション自身がクライアントだ。アプリケーションはサーバーと通信して、 リクエストを出し、さらにサーバーから情報を受けとる。

X サーバーはディスプレイとクライアントからのサービスリクエストを 独占的に制御し続けている。この点で、このモデルを使う利点はまったく明白 だ。アプリケーション(つまりクライアント)が知らなきゃいけないのは、 どうやってサーバーと通信するかだけであって、実際のグラフィックスディスプレイ デバイスとの話の詳細には関心を払う必要がないんだ。もっとも基本的なレベル では、クライアントは、「ここからあそこまで線を描け」とか「このテキスト 文字列を描写しろ、フォントはこれを使って、画面上のこの位置に」とかいう ものをサーバーに教えるんだ。

これはグラフィックスライブラリを使ってアプリケーションを書くのと、 何の違いもないだろうと思う。でも X のモデルはもっと先を行っている。 クライアントがサーバーと同じコンピュータになきゃいけないなんて強制は しないんだ。クライアントとサーバーの間で通信するのに使うプロトコルは、 ネットワーク越しでも動作できるし、実際「信頼性の高い octet-stream を提供する プロセス間通信の機構」ならなんだって動作できるんだ。もちろん、好ましいのは TCP/IP プロトコルを使って通信することさ。これまで見てきたように、 X のモデル は実に強力なんだ。これに関する古典的な例としては、プロセッサーを集中的に使う アプリケーションを Cray コンピュータで動かして、データベースモニターを Solaris サーバーで動かして、電子メールアプリケーションを小型の BSD メール サーバーで動かして、さらにグラフィックスを使ったプログラムをSGIサーバーで 動かして、そうしておいてから、 自分の Linux ワークステーションの画面で、 それらすべての表示を行なうっていうのがある。

これまでのところ、 X サーバーは実際のグラフィックスディスプレイを 扱うものだということがわかった。さらに、ユーザーが作業している物理的な 実際のコンピュータで動いているのが X サーバーだから、そのユーザーとの 実際のやりとりすべてを実行する責任があるのも X サーバーだ。これには マウスやキーボードの動きを読みとることも入る。この情報はすべてクライアントに 中継されるから、クライアントは、もちろんこれに対して反応しなければ ならないだろうね。

X はその名前にふさわしく、 Xlib という名前のライブラリを提供している。 これは低レベルのクライアント - サーバー通信のタスクすべてを処理してるんだ。 だから明らかだと思うけど、クライアントが仕事をしてしまうには 、Xlib の 中にある関数を実行しなきゃならないんだ。

この時点ではすべてがうまく動いてるようだ。出力を目に見える形で出すことと データの入力、クライアントアプリケーション、そしてそれらが互いに通信する 方法、この3つを担当しているサーバーが自分たちにはある。クライアントと サーバーの間で、相互に仮想的なやりとりがあるとして、その光景を思い描いて みるとだ、画面上に矩形の領域を割り振ってくれと、クライアントはサーバーに 頼むだろう。クライアントにしてみれば、画面上のどこに自分が表示されているか なんてことはどうでもいいんだ。「横 X ピクセル、縦 Y ピクセルの大きさの 領域をよこせ」ってサーバーに伝えてるだけなんだ。それから関数を呼び出して、 「ここからあそこまで線を引け」とか「画面のこの領域の中でユーザーがマウスを 動かしているかどうか教えてくれ」とかいったような行動を起こすんだ。