私はWindowsシステムになぜサーバーが必要なのかわかりませんでした。デスクトップ環境、ディスプレイマネージャ、ウィンドウマネージャにxorg-serverが必要なのはなぜですか？グラフィックカードの上に抽象化レイヤーしかありませんか？ Windowsシステムがクライアントサーバーモデルを使用するのはなぜですか？名前付きパイプを介してプロセス間通信を実行する方が簡単ではありませんか？
答え1
私はあなたが何らかの「サーバー」が必要であることに気づいたと思います。各クライアント（デスクトップ環境、ウィンドウマネージャ、またはウィンドウプログラム）は、他のすべてのクライアントとディスプレイを共有し、ハードウェアの詳細やディスプレイを使用している他の人を知らなくてもコンテンツを表示できる必要があります。したがって、X11サーバーはIPCインターフェースを提供し、前述の抽象化と共有層を提供します。
X11は、名前付きパイプで実行できますが、名前付きパイプでは実行できない2つの大きなタスクがあります。
- 名前付きパイプは一方向にのみ通信します。
- 両方のプロセスが名前付きパイプの「転送」の末尾にデータを挿入し始めると、データは一緒に混在します。
実際、ほとんどのXクライアントは、UNIXドメインソケットと呼ばれる「新しく拡張された」名前付きパイプを使用してサーバーと通信します。これは、プロセスが双方向で通信し、誰が何を言ったのかを追跡できることを除いて、名前付きパイプと非常によく似ています。これはネットワーキングが実行する必要があるすべての操作なので、UNIXドメインソケットはネットワーク通信を提供するTCP / IPソケットと同じプログラミングインターフェースを使用します。
しかし、ここでは、「クライアント以外のホストでサーバーを実行するとどうなりますか？」と言うのは簡単です。 UNIXソケットの代わりにTCPソケットを使用するだけです。チャジャン、これはWindows RDPよりも数年前の方法です。リモートデスクトッププロトコル。ssh4つの異なるリモートホストに接続し、各ホストで（グラフィックパッケージマネージャ）を実行でき、synaptic4つのウィンドウがすべて自分のローカルコンピュータのディスプレイに表示されます。
答え2
Windowsシステムにはサーバーは必要ありませんが、クライアントサーバーモデルに基づいてWindowsシステムを実装することを決定できます。これにはいくつかの利点があります。クライアントとサーバーのアクティビティを明確に分離でき、同じシステムで実行する必要がなく、複数のクライアントにサービスを提供する方が簡単です。これは現時点では非常に便利ですが（たとえば、ssh別のコンピュータに入るときなど）、Xを開発するときにこれが必須と見なされることに注意してください。ローカルコンピュータがクライアントを実行するのに十分強力ではない可能性があります。
名前付きパイプは、TCP実装のようにネットワーク上で実行できるという利点を自動的に提供しません。ただし、名前付きパイプはDOSでは使用できず、DosExtenderはDesqview / X（1992）を実行し、AFAIKはVMSでも使用できません。この実装では、Unix関連の通信が問題になります。
TCPはUnixに限定されず、クライアントはVAX / VMS（X開発は1984年に開始）で実行され、デフォルトのUNIXベースのグラフィックワークステーションに出力を提供できます。 「Xウィンドウシステム：Xlib、Xプロトコル、ICCCM、XLFDへの完全な参照」1から：
1986年の秋、Digitalは、ULTRIX、VMS、およびMS-DOSのフルデスクトップワークステーション戦略をXベースにすることにしました。これは私たちに慰めにもなりますが、会話する人がより多くなるという意味でもあります。これにより若干の遅延が発生しましたが、最終的にはより良いデザインにつながりました。 DigitalのRalph Swickはこの期間中にProject Athenaに参加し、バージョン11の開発に重要な役割を果たしました。最後のバージョンであるバージョン10は1986年12月にリリースされました。
「Xプロトコルリファレンスマニュアル」²から：
責任の分割
Xプロトコルを設計するとき、私たちは、要求、応答、およびイベントを通じてどの情報を前後に渡すべきかを決定するサーバーとクライアント間の機能の分割について多くの考えをしました。設計プロトコルの特定の選択の背後にある理論的根拠に関する優れた情報源は、Transaction on Graphics、Issue 5 Volume、Issue 10に掲載されたRobert W. ScheiflerとJim Gettysの「The X Window System」の記事です。 1986年4月2日に行われた最終決定は、クライアントプログラムの移植性、クライアントプログラミングの容易さ、およびパフォーマンスに基づいて行われました。
まず、サーバーは、クライアントアプリケーションとの基本的なハードウェアの違いを最大限に隠すように設計されています。 ...
TOGに関する記事が興味深かった記憶があります。それはXへの私の関心を引き起こしました（これはWorld Wide Webの前でした）、O'ReillyがXシリーズの本を公開し始めるまではるかに多くの情報を得ることは困難でした。
¹Xバージョン11、4版、2-Xページ、PDFオンライン利用可能ここ
²これは私が1990年に購入したO'Reillyによって発行された第2版の9ページです。最新バージョンがありますが、私はあえてこれを購入したことがなく、私が知っている限り、このバージョンはハードコピーでのみ入手できます。私は彼らが責任分担の根拠を変えたとは思わない。
答え3
Windowsシステムは、複数の独立したプログラムが共通のリソース、画面、および入力デバイスを共有することを意味します。リソース共有は、次の2つの方法でのみ安全に実行できます。
- リソースはカーネルによって制御でき、アプリケーションはカーネルを呼び出してリソースにアクセスできます。
- リソースは専用プロセス（サーバー）によって制御でき、アプリケーションはリソースにアクセスするためにサーバーに接続します。
もちろん、実際のディスプレイハードウェアへのアクセスはカーネルによって制御されますが、Windowsシステムではこれだけでは不十分です。部分他のプロセスがディスプレイ（ウィンドウ）を妨害しないことは合理的に確信でき、どのアプリケーションがいつリソースのどの部分にアクセスできるかについて、ある程度の保護を提供する必要があります。
これで、すべてがカーネルに入ることができます。私が知っている限り、Windowsはこれらのことを行います。これの利点はより速いことです（通常、カーネルを呼び出す方が他のプロセスにアクセスするよりもはるかに高速です）。ただし、セキュリティホールを開くことができるという欠点があります（システムのすべての抜け穴はカーネルレベルの抜け穴です）。制限は移植性です（カーネルに実装されているシステムはカーネルと強く結合されているため、カーネルコードにアクセスできない限り、まったく別のオペレーティングシステムに簡単に移植することはできません）。
カーネルで実装したくない場合は、それを実装する唯一の方法は専用プロセス、つまりサーバーとして実装することです。名前付きパイプを介して接続されたサーバーはまだサーバーです。さらに、同じシステムで実行されている場合、Xサーバーとクライアント間の通信のほとんどは共有メモリを介して行われますが、ディスプレイサーバーがサーバーであるという事実はまだ変わりません。
サーバーに接続するために名前付きパイプの代わりにソケットを使用するのはなぜですか？さて、これを行うためにソケットを使用する場合は、すべての通信のためにサーバー全体に単一のソケットを提供するだけです。通信にパイプを使用する場合は、クライアントごとに2つのパイプが必要です。これらすべてのパイプを管理する手間に加えて、十分なプログラムが同時にサーバーと通信しようとすると、開いているパイプの数にオペレーティングシステムの制限が発生する可能性があります。
もちろん、パイプに比べてソケットが持つもう1つの利点は、ソケットを使用すると、複数のマシンに接続できることです。これは、専用端末に座っている多くの人が実際のコンピュータを共有する時代に特に重要でした。しかし、今日のネットワーク環境でもまだ非常に便利です。
答え4
クライアント - サーバーモデルは、サーバーとクライアントが1つしかない場合でも、さまざまなアプリケーションで広く使用されているデザインです。責任領域間で明確で明確に定義されたインターフェースを許可します。
Xサーバーとクライアントはさまざまな方法で通信できますが（他の人が言及した利点に関係なく）、選択したものは重複しません。できる別のコンピュータのサーバーに接続し、Xデスクトップ（または他のコラボレーションデスクトップ）でウィンドウを開きます。これは、多くの大学や企業がUnixサーバーと通信できる多くの「X端末」を持っていたX開発時代に非常に一般的でした。インターネットに準備された通信プロトコルを使用することにより、Ｘはホスト内またはホスト間でシームレスに使用できる。
Xは、単一コンピュータのシングルユーザーオペレーティングシステムではなく、マルチユーザー環境としてのUNIXの歴史と一致して、他のコンピュータのウィンドウを透過的に表示できる最初のGUI環境でした。コンピュータと物理的またはリモートで対話できる唯一の人は、多くのUNIX機能が過度に見える可能性があります。