X Window Systemがサーバーを使用するのはなぜですか？

ウィンドウシステムにサーバーが必要な理由を理解できませんでした。デスクトップ環境、ディスプレイマネージャー、ウィンドウマネージャーにxorg-serverが必要なのはなぜですか？グラフィックスカードの上に抽象化レイヤーを配置するだけですか？ウィンドウシステムがクライアントサーバーモデルを採用しているのはなぜですか？名前付きパイプを介したプロセス間通信は簡単ではないでしょうか？

ある種の「サーバー」が必要であることにすでに気づいていると思います。各クライアント（デスクトップ環境、ウィンドウマネージャー、またはウィンドウプログラム）は、他のすべてのユーザーとディスプレイを共有する必要があり、ハードウェアの詳細を知らずに、またはディスプレイを使用している人を知らなくても、物を表示できる必要があります。そのため、X11サーバーは、IPCイン​​ターフェイスを提供することで、前述の抽象化と共有のレイヤーを提供します。

X11はおそらく名前付きパイプで実行することができますが、名前付きパイプではできない2つの大きなことがあります。

• 名前付きパイプは一方向にのみ通信します。
• 2つのプロセスが名前付きパイプの「送信」側にデータを配置し始めると、データが混ざります。

実際、ほとんどのXクライアントは、UNIXドメインソケットと呼ばれる「新しく改善された」名前付きパイプを使用してサーバーと通信します。これは、名前付きパイプによく似ていますが、プロセスが両方向に通信でき、誰が何を言ったかを追跡できます。これらはネットワークがしなければならないものと同じ種類のものであるため、UNIXドメインソケットは、ネットワーク通信を提供するTCP / IPソケットと同じプログラミングインターフェイスを使用します。

しかし、そこから、「サーバーをクライアントとは異なるホストで実行した場合はどうすればよいか」と言うのは本当に簡単です。UNIXソケットの代わりにTCPソケットを使用するだけで、できあがり：Windows RDPに数十年前から使用されていたリモートデスクトッププロトコルです。ssh4つの異なるリモートホストにアクセスしsynapticて、それぞれで（グラフィカルパッケージマネージャー）を実行すると、4つのウィンドウがすべてローカルコンピューターのディスプレイに表示されます。

ウィンドウシステムにはサーバーは必要ありませんが、クライアントサーバーモデルに基づいてウィンドウシステムを実装することもできます。クライアントとサーバーのアクティビティを明確に分離し、同じマシンで実行する必要がなく、複数のクライアントにサービスを提供するのがより簡単であるため、これにはいくつかの利点があります。これは現在でも非常に便利ですが（たとえば、ssh別のマシンを使用する場合）、Xが開発された時点でそれが必要であると認識していたことを理解する必要があります。

名前付きパイプは、TCP実装のようにネットワーク上で実行できるという自動的な利点を提供しません。しかし、DosExtenderがDesqview / X（1992）を実行している場合、名前付きパイプはDOSでは使用できません。これらの実装では、Unix固有の通信が問題になります。

TCPはUnix固有ではなく、VAX / VMS（1984年に開始されたX開発）でクライアントを実行し、ローカルUNIXベースのグラフィックワークステーションに出力を提供することができます。「X Window System：Xlib、Xプロトコル、ICCCM、XLFDへの完全なリファレンス」¹から：

1986年の秋、DigitalはULTRIX、VMS、およびMS-DOSのデスクトップワークステーション戦略全体をXに基づいて決定することを決定しました。これにより、多少の遅延が生じましたが、最終的にはより良い設計になりました。DigitalのRalph Swickはこの期間中にProject Athenaに参加し、バージョン11の開発を通じて重要な役割を果たしました。最後のバージョン10リリースは、1986年12月に利用可能になりました。

「Xプロトコルリファレンスマニュアル」²から：

責任の分担

Xプロトコルの設計プロセスでは、サーバー、クライアント間の機能の分割について多くの検討が行われました。これにより、要求、応答、イベントを通じてどの情報をやり取りする必要があるかが決まります。プロトコルの設計における特定の選択の背後にある理論的根拠に関する優れた情報源は、Robert W. ScheiflerとJim GettysによるThe 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つの方法でのみ安全に実装できます。

• リソースはカーネルによって制御される場合があり、アプリケーションはそれにアクセスするためにカーネル呼び出しを行います。
• リソースは専用プロセス（サーバー）によって制御され、アプリケーションはサーバーにアクセスしてアクセスします。

もちろん、実際の表示ハードウェアへのアクセスは、カーネルによって制御されるが、それはウィンドウシステムのための十分ではありませんされます。プロセスは、特定の割り当てを取得するための方法がなければならない部分、それが合理的にすることができ、ディスプレイ（画面）のを他のプロセスが干渉しないことを確認し、どのアプリケーションがどの時点でリソースのどの部分にアクセスできるかについて、一定レベルの保護が必要です。

これですべてがカーネルに組み込まれた可能性があります。これは、Windowsが行っていることと同じです。これには高速であるという利点があります（通常、カーネルの呼び出しは別のプロセスに接続するよりもはるかに高速です）が、セキュリティホールを開く可能性があるという欠点があります（システムの悪用はカーネルレベルでの悪用です）。時間は移植性を制限します（カーネルに実装されたシステムはカーネルに強く結合されています。他のオペレーティングシステムに簡単に移植することはできず、カーネルコードにアクセスできない場合は完全に移植できません）。

カーネルに実装したくない場合、それを実装する唯一の他の方法は、専用のプロセス、つまりサーバーとしてです。名前付きパイプを介して接続されるサーバーは、依然としてサーバーであることに注意してください。また、同じマシンで実行している場合、Xサーバーとクライアント間の多くの通信は、最近では共有メモリを介して行われます。それでも、表示サーバーがサーバーであるという事実は変わりません。

さて、なぜ名前付きパイプを使用せずにソケットを使用してサーバーに接続するのですか？ソケットを使用してそれを行う場合、サーバー全体に対して1つのソケットがあれば十分です。これにより、すべての通信を行うことができます。パイプと通信する場合、クライアントごとに2つのパイプが必要です。これらすべてのパイプを管理するのは非常に面倒であるという事実とは別に、十分な数のプログラムが同時にサーバーと通信しようとすると、開いているパイプの数がオペレーティングシステムの制限に達する可能性があります。

そしてもちろん、パイプに対するソケットのもう1つの利点は、ソケットを使用してマシン間で接続できることです。これは、実際のコンピューターが専用端末に座っている多くの人々と共有されていたため、コンピューター上のプログラムが通信する必要があったときに特に重要でしたさまざまな端末に接続できますが、ネットワーク化された環境でも今日でも非常に便利です。

XはもともとMITによって開発および保守されていました。そして、オープンソースのMITライセンスがありましたが、それは本当に重要なことです。

慣例に反していると思われますが、しばらく検討してください。ソフトウェアでクライアントサーバーパラダイムを使用する選択をどのように説明しますか？そして、おそらく私はCEOに言うべきです。

大学での選択を高く評価する方法を学びました。クライアントサーバーでは、サーバーがリソース、特に共有する必要のあるリソースを管理します。そのため、Xサーバーは、クライアントアプリ、キーボード、マウス、およびフレームバッファーにサービスを提供するプロセスです（ただし、システムの画面に書き込むこともできます）。

本当に正しいわけではありませんが、ウィンドウマネージャーは次のように説明されることがよくあります。それは、単に、アプリのフレームやウィンドウ、ダイアログなどにハンドルやその他の装飾を置くことです。

クライアントサーバーモデルは、1つのサーバーと1つのクライアントしかない場合でも、あらゆる種類のアプリケーションに人気のあるデザインです。これらにより、責任ドメイン間で明確で明確に定義されたインターフェースが可能になります。

サーバーとクライアントが通信できる方法は数多くありますが、X（他の人が述べた利点に関係なく）行われた選択は不要ではありません：別のマシンのサーバーに接続し、デスクトップ（または連携する別のマシン）でウィンドウを開くことができXますデスクトップ）。これは、Xが開発された時代に非常に一般的でした。多くの大学や企業では、Unixサーバーとそれに通信する多くの「X端末」を使用していました。インターネット対応の通信プロトコルを使用することにより、Xはホスト内またはホスト間でシームレスに使用できます。

Xは、別のマシンからウィンドウを透過的に表示できる最初のGUI環境であり、単一コンピューター上の単一ユーザーのOSではなく、マルチユーザー環境としてのUNIXの歴史と一致しています。UNIXの機能の多くは、コンピューターと（物理的またはリモートで）対話することができるのがあなただけである場合、過剰に思えます。

最初はコンピューティングリソースが不足しており、メインフレームがほとんどの重労働を行っていたため、Xサーバーはクライアントサーバーアーキテクチャとして設計されたと思います。X端末は、xサーバーに接続し、ユーザーに表示する必要があるものをすべて表示する単なるシンクライアントでした。

Xには多くの利点がありますが（Xの通信プロトコルは現在非常に重いですが）、特に複数のクライアントで同じディスプレイを表示でき、Xでは複数のユーザーと画面を共有するのが簡単です。