Server-Client model

サーバ/クライアント モデルについて質問があったので解説しときます．

サーバ/クライアントというのは名前のとおり
ある種のサービスを要求するクライアントとなる計算機と
そのサービスを行う計算機が必ずしも同一ではない
という状況での情報処理形態です．
と言えば，難しく聞こえますが，
たとえば，ファイルサーバを例にとれば，
何とかというファイルの内容を教えてくれというのがクライアント，
これこれこういった内容ですよん！と教えてくれるのがサーバです．

(ユーザの近く)						(ユーザの遠く)
クライアント	--(ファイル"foo"の内容教えて)-->	サーバ
							"foo"を読み込む
クライアント	<--(そいつは，これこれだよ)--   	サーバ

って感じかな？ようするに情報はサーバがにぎってて
それをクライアントに通知したり，
クライアントからの変更要求に応じて変更したりするってもんです．

が，しかし！
unixで使用されるX Window Systemにおいては，
ファイルサーバの例とは大きな違いがあります．
それは，ユーザの近くにあるのがサーバで，遠くにあるのがクライアントなのです．
ファイルサーバにおいては，
入出力というのはすなわちファイルへの読み書きですが，
ウィンドウシステムにおいては，
入出力というのは，マウスの状態通知と画面出力です．
ですから，

(ユーザの近く)						(ユーザの遠く)
サーバ		--(マウスのボタン1が押された)-->	クライアント
							ドット打たなきゃ
サーバ		<--(ここにドット打ってくれ)--		クライアント

てな具合になるわけです．

ここで重要なのは，Xのアプリはクライアントで動作しているということ．
fkissで例えるなら，自分の使ってる計算機のマウスの情報が
もしかしたら遠くの計算機で動作してるfkiss自身に通知され
その結果の画面情報の更新内容がその遠くの計算機から
自分の使ってる計算機に通知されて画面が更新されるという手順なのです．

こういったモデルでは，サーバとクライアントの交信は
できるだけ簡潔であることが要求されます．
マウスのボタンの状態の通知などは簡単なのですが，
画面情報については毎度毎度多量のデータになってしまいます．
これを避けるために，
あらかじめサーバにビットマップ情報を憶えておいてもらって
クライアントは，
これとこれとこれのビットマップを重ね合わせてココに表示して！
という情報だけを送るようにするわけです．
これだと最初にビットマップ情報をクライアントからサーバに送るだけで，
後はそのプットに関する要求を通知するだけですむわけです．

で，KISSのTrue color化に関する問題点として，
現状のXについては，これこれの透明度でプットしてね！って手段がないのです．
だからこれを実現するとなると
ピクセルイメージを転送しないといけなくなって
これはかなり転送バンドを消費してしまうわけです．
(このへん X Image Extansionである程度考慮してあるかも)

というのが，KISS True color化に関する懸念です．
もっとも，これらの問題はサーバとクライアントが同一である場合には
(もっとも，ほとんどのfkiss実行において同一だと思いますが)
大した問題にならないのですが，
こんなこともちょっと頭の片隅にでもおいておくといいかもしれません．
MS-Windows等でも現状ではサーバ=クライアントですけど，
いつサーバ/クライアントの分離が起きても不思議ではないと思いますよん．
(っていうより，どうして現状でやってないのかが不思議だ!?
 さすが，5年昔をいく設計って感じ)

簡単に説明したんで，ウソ多いと思うし，
よく解らんとも思うんでツッコミよろしく．

                                        UHD98984@pcvan.or.jp
                                                        yav