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