X Window Systemがサーバーを使用するのはなぜですか？
なぜウィンドウシステムにサーバーが必要なのか、本当に理解できませんでした。デスクトップ環境、ディスプレイマネージャー、ウィンドウマネージャーにxorg-serverが必要なのはなぜですか？グラフィックカードの上に抽象化レイヤーを置くだけですか？ウィンドウシステムはなぜクライアントサーバーモデルを採用するのですか？名前付きパイプを介したプロセス間通信の方が簡単ではないでしょうか？
なんらかの「サーバー」が必要であることにすでに気付いたと思います。各クライアント（デスクトップ環境、ウィンドウマネージャー、またはウィンドウプログラム）は、他のすべてのクライアントとディスプレイを共有する必要があり、ハードウェアの詳細を知らなくても、または他にだれがディスプレイを使用しているかを知らなくても、表示できる必要があります。つまり、X11サーバーは、IPCインターフェースを提供することにより、前述の抽象化と共有のレイヤーを提供します。
X11はおそらく名前付きパイプで実行するように作成できますが、名前付きパイプでは実行できない2つの大きなことがあります。
- 名前付きパイプは一方向にのみ通信します。
- 2つのプロセスが名前付きパイプの「送信」側にデータを送信し始めると、データが混在します。
実際、ほとんどのXクライアントは、UNIXドメインソケットと呼ばれる「新しく改善された」名前付きパイプを使用してサーバーと通信します。これは名前付きパイプによく似ていますが、プロセスが両方向で会話できることと、誰が何を言ったかを追跡します。これらはネットワークで実行する必要があるものと同じようなものなので、UNIXドメインソケットは、ネットワーク通信を提供するTCP/IPソケットと同じプログラミングインターフェイスを使用します。
しかし、そこからは、「クライアントとは異なるホストでサーバーを実行した場合はどうなるのか」と言うのはとても簡単です。 UNIXソケットの代わりにTCPソケットを使用して、出来上がり：Windows RDPより数十年前にリリースされたリモートデスクトッププロトコルです。4つの異なるリモートホストにsshを実行して実行できます。それぞれにsynaptic（グラフィカルパッケージマネージャー）を追加すると、4つのウィンドウすべてがローカルコンピューターのディスプレイに表示されます。
ウィンドウシステムにはサーバーがなくてもかまいませんが、クライアントサーバーモデルに基づいてウィンドウシステムを実装することができます。これにより、クライアントとサーバーのアクティビティを明確に分離できるため、いくつかの利点があります。それらを同じマシンで実行する必要がなく、複数のクライアントにサービスを提供することがより簡単になります。これは現在でも非常に便利です（たとえば、別のマシンにsshを使用する場合）。ただし、Xが開発された時点では、それは必要であると見なされていました。ローカルマシンは、クライアントを実行します。
名前付きパイプは、TCP実装のようにネットワーク上で実行できるという自動的な利点を与えません。しかし、名前付きパイプは、例えば、DOSで利用できず、Desqview/X（ 1992）、AFAIKもVMSにはありません。これらの実装では、Unix固有の通信が問題になります。
TCPはUnix固有ではなく、クライアントをVAX/VMS（1984年にX開発を開始）で実行し、ローカルのUNIXベースのグラフィックワークステーションに出力を提供することが可能です。 「Xウィンドウシステム：Xlib、Xプロトコル、ICCCM、XLFDへの完全なリファレンス」から：
1986年の秋、DigitalはULTRIX、VMS、およびMS-DOS向けのデスクトップワークステーション戦略全体をXに基づいて決定することを決定しました。これは私たちにとって満足のいくものでしたが、さらに多くの人と話をする必要がありました。これにより多少の遅延が発生しましたが、最終的には設計が改善されました。デジタルのRalph Swickはこの期間にProject Athenaに加わり、バージョン11の開発を通じて重要な役割を果たしました。最後のバージョン10リリースは1986年12月に利用可能になりました。
「Xプロトコルリファレンスマニュアル」²から：
責任分担
Xプロトコルの設計プロセスでは、サーバーとクライアント間の機能の分割について多くの検討が行われました。これにより、要求、応答、イベントを通じてどの情報をやり取りする必要があるかが決まります。プロトコルの設計で行われた特定の選択の背後にある根拠に関する優れた情報源は、Robot W. ScheiflerとJim GettysによるThe X Window Systemで、Association of Computing MachineryジャーナルTransaction on Graphics、Vol 5、No。 1986年4月2日最終的に到達した決定は、クライアントプログラムの移植性、クライアントプログラミングの容易さ、およびパフォーマンスに基づいていました。
まず、サーバーは、クライアントアプリケーションから基盤となるハードウェアの違いをできるだけ隠すように設計されています。 ...
TOGの記事が興味深い読み物だったことを覚えています。それは確かにXへの興味と（これはWorldWideWebの前でした）トリガーとなりました。O'ReillyがXシリーズの本の出版を開始するまで、より多くの情報を手に入れるのが困難でした。
¹ Xバージョン11、リリース4、ページ2-X、PDFオンラインで入手可能 こちら
² これは、1990年に購入したO'Reillyの第2版の9ページからです。新しいエディションはありますが、購入する気にならなかったので、AFAIKは紙でも入手できます。彼らが責任分担の理論的根拠を変えたとは思いません。
ウィンドウシステムとは、いくつかの独立したプログラムが、共通のリソースである画面と入力デバイスを共有することを意味します。共有リソースは、次の2つの方法でのみ安全に実装できます。
- リソースはカーネルによって制御される場合があり、アプリケーションはそれにアクセスするためにカーネル呼び出しを行います。
- リソースは専用プロセス（サーバー）によって制御され、アプリケーションはサーバーにアクセスしてアクセスします。
もちろん、実際のディスプレイハードウェアへのアクセスはカーネルによって制御されますが、ウィンドウシステムには十分ではありません。プロセスに特定のディスプレイのpartを割り当てる方法が必要です（ウィンドウ）他のプロセスが干渉しないことが合理的に確実であり、どのアプリケーションがどの時点でリソースのどの部分にアクセスできるかについて、一定レベルの保護が必要です。
さて、すべてがカーネルに入り込んでいる可能性があります。これは、Windowsが行っていることです。これには高速であるという利点があります（通常、カーネルの呼び出しは別のプロセスに連絡するよりもはるかに高速です）が、セキュリティホールを開く可能性があるという欠点があります（システムの悪用はカーネルレベルの悪用です）。時間は移植性を制限します（カーネルに実装されたシステムはカーネルに強く結合しています。別のオペレーティングシステムに簡単に移植できず、カーネルコードにアクセスできない場合は完全に移植できません）。
それをカーネルに実装したくない場合、それを実装する他の唯一の方法は、専用プロセス、つまりサーバーとしてです。名前付きパイプを介して接続されるサーバーはサーバーであることに注意してください。また、同じマシンで実行している場合、Xサーバーとクライアント間の通信の多くは、最近の共有メモリを介して行われます。それでも、表示サーバーがサーバーであるという事実は変わりません。
では、なぜサーバーはソケットを使用して接続され、名前付きパイプを使用しないのですか？ソケットを使用する場合は、サーバー全体に対して1つのソケットがあれば十分です。これにより、すべての通信を実行できます。パイプと通信する場合、クライアントごとに2つのパイプが必要です。これらのパイプをすべて管理するのは非常に煩雑であるという事実は別として、十分な数のプログラムが同時にサーバーと通信しようとすると、オープンパイプの数に関するオペレーティングシステムの制限に達する可能性があります。
そしてもちろん、パイプ上のソケットのもう1つの利点は、ソケットを使用するとマシン間で接続できることです。これは、実際のコンピューターが専用端末に座っている多くの人々と共有されていたため、コンピューター上のプログラムが通信する必要があったときに特に重要でしたさまざまな端末に接続できますが、現在でもネットワーク環境で非常に役立ちます。
Xは、もともとM.I.Tによって開発および保守されていました。そして、それはオープンソースのM.I.Tライセンスでしたが、それが実際に重要なことではありません。
型にはまらないと思われる間、しばらく考えてください。ソフトウェアでクライアントサーバーパラダイムを使用する選択をどのように説明しますか？そして、おそらく私はC.E.Oに言うべきです...
これが私が大学での選択に感謝する方法を学びました。クライアントサーバーでは、サーバーがリソースを管理し、特に、でなければならないすべてのリソースがshared。つまり、Xサーバーはclientアプリ、キーボード、マウス、フレームバッファ（または、システム上の画面）。
実際には正しくありませんが、ウィンドウマネージャーは次のように説明されることがよくあります。それは単に、アプリのフレーム、ウィンドウ、ダイアログなどにハンドルやその他の装飾を配置することです。
クライアントサーバーモデルは、サーバーが1つ、クライアントが1つしかない場合でも、あらゆる種類のアプリケーションで一般的な設計です。それらは、責任のドメイン間の明確で明確なインターフェースを可能にします。
サーバーとクライアントが通信する方法はたくさんありますが、Xによる選択（他の人が述べた利点に関係なく）は不必要ではありません：あなたcanXサーバーを別のマシンに置き、デスクトップ（または他の連携デスクトップ）でウィンドウを開きます。これは、多くの大学や企業がUnixサーバーとそれに通信する多くの「X端末」を備えていたXが開発された時代には、非常に一般的でした。 インターネット対応の通信プロトコルを使用することにより、Xはホスト内またはホスト間でシームレスに使用できます。
Xは、別のマシンからウィンドウを透過的に表示できる最初のGUI環境であり、単一のコンピューター上の単一ユーザー用のOSではなく、マルチユーザー環境としてのUNIXの歴史と一致しています。コンピューターと（物理的またはリモートで）対話できる唯一のユーザーである場合、UNIXの多くの機能はやり過ぎに見えます。