Warum verwendet das X Window System einen Server?

Ich habe nie wirklich verstanden, warum ein Fenstersystem einen Server haben muss. Warum benötigen Desktop-Umgebungen, Display-Manager und Window-Manager einen xorg-Server? Ist es nur eine Abstraktionsebene über der Grafikkarte zu haben? Warum verwenden Fenstersysteme ein Client-Server-Modell? Wäre die Kommunikation zwischen Prozessen über Named Pipes nicht einfacher?

Ich denke, Sie haben bereits bemerkt, dass eine Art "Server" benötigt wird. Jeder Client (Desktop-Umgebung, Fenstermanager oder Fensterprogramm) muss die Anzeige für alle anderen freigeben, und er muss in der Lage sein, Dinge anzuzeigen, ohne die Details der Hardware zu kennen oder zu wissen, wer die Anzeige sonst noch verwendet. Der X11-Server bietet also die von Ihnen erwähnte Abstraktions- und Freigabeebene, indem er eine IPC-Schnittstelle bereitstellt.

X11 könnte wahrscheinlich über Named Pipes laufen, aber es gibt zwei große Dinge, die Named Pipes nicht können.

• Named Pipes kommunizieren nur in eine Richtung.
• Wenn zwei Prozesse beginnen, Daten in das "sendende" Ende einer Named Pipe zu schreiben, werden die Daten vermischt.

Tatsächlich kommunizieren die meisten X-Clients mit dem Server über eine "neue und verbesserte" Named Pipe, die als UNIX-Domain-Socket bezeichnet wird. Es ähnelt einer Named Pipe, lässt jedoch Prozesse in beide Richtungen kommunizieren und protokolliert, wer was gesagt hat. Dies sind dieselben Aufgaben, die das Netzwerk ausführen muss. Daher verwenden UNIX-Domain-Sockets dieselbe Programmierschnittstelle wie die TCP / IP-Sockets, die die Netzwerkkommunikation bereitstellen.

Aber von dort aus ist es wirklich einfach zu sagen: "Was ist, wenn ich den Server auf einem anderen Host als dem Client ausgeführt habe?" Verwenden Sie einfach einen TCP-Socket anstelle des UNIX-Sockets und voila: ein Remotedesktopprotokoll, das um Jahrzehnte älter ist als Windows RDP. Ich kann sshauf vier verschiedenen Remote-Hosts ausführen synaptic(grafischer Paket-Manager), und alle vier Fenster werden auf dem Bildschirm meines lokalen Computers angezeigt.

Ein Fenstersystem muss keinen Server haben, aber Sie können sich dafür entscheiden, ein Fenstersystem basierend auf einem Client-Server-Modell zu implementieren. Dies hat mehrere Vorteile, da Sie die Aktivitäten auf dem Client und dem Server klar voneinander trennen. Sie müssen nicht auf demselben Computer ausgeführt werden, und es ist einfacher, mehrere Clients zu warten. Das ist derzeit noch sehr praktisch (z. B. wenn Sie sshin eine andere Maschine einsteigen), aber Sie müssen feststellen, dass zum Zeitpunkt der Entwicklung von X dies als eine Notwendigkeit angesehen wurde: Ihre lokale Maschine ist möglicherweise nicht leistungsfähig genug, um den Client auszuführen.

Named Pipes bieten nicht den automatischen Vorteil, dass Sie wie bei einer TCP-Implementierung über das Netzwerk ausgeführt werden können. Named Pipes waren zB unter DOS nicht verfügbar, mit DosExtender unter Desqview / X (1992) und AFAIK auch nicht unter VMS. Für diese Implementierungen wäre eine Unix-spezifische Kommunikation ein Problem.

TCP ist nicht Unix-spezifisch und es ist möglich, einen Client unter VAX / VMS (X-Entwicklung ab 1984) auszuführen und die Ausgabe an Ihre lokale UNIX-basierte Grafik-Workstation zu liefern. Aus dem "X Window System: Die vollständige Referenz zu Xlib, X Protocol, ICCCM, XLFD" ¹:

Im Herbst 1986 entschied sich Digital, seine gesamte Desktop-Workstation-Strategie für ULTRIX, VMS und MS-DOS auf X zu stützen. Dies war für uns zwar erfreulich, bedeutete aber auch, dass wir noch mehr Leute zum Reden hatten. Dies führte zu einer gewissen Verzögerung, letztendlich aber auch zu einem besseren Design. Ralph Swick von Digital schloss sich in dieser Zeit dem Projekt Athena an und spielte während der Entwicklung von Version 11 eine wichtige Rolle. Die letzte Version 10 wurde im Dezember 1986 veröffentlicht.

Aus dem "X Protocol Reference Manual" ²:

Aufgabenteilung

Bei der Entwicklung des X-Protokolls wurde viel über die Aufteilung der Funktionen zwischen Server und Client nachgedacht. Dabei wird festgelegt, welche Informationen durch Anforderungen, Antworten und Ereignisse hin und her geleitet werden müssen. Eine ausgezeichnete Informationsquelle über die Gründe für bestimmte Entscheidungen beim Entwurf des Protokolls ist der Artikel The X Window System von Robert W. Scheifler und Jim Gettys, veröffentlicht in der Fachzeitschrift Transaction on Graphics der Association of Computing Machinery, Band 5, Nr. 2, April 1986 Die letztendlich getroffenen Entscheidungen basierten auf der Portabilität von Client-Programmen, der Einfachheit der Client-Programmierung und der Leistung.

Erstens ist der Server so konzipiert, dass Unterschiede in der zugrunde liegenden Hardware gegenüber Clientanwendungen so gut wie möglich ausgeblendet werden. ...

Ich erinnere mich, dass der Artikel in TOG eine interessante Lektüre war. Es löste mit Sicherheit mein Interesse an X aus und (dies war vor dem WorldWideWeb) die Schwierigkeit, mehr Informationen in die Hände zu bekommen, bis O'Reilly begann, ihre Bücher der Serie X zu veröffentlichen.

¹ _{X Version 11, Release 4, Seite 2-X, PDF hier online verfügbar}
² _{Dies ist von Seite 9 in der zweiten Ausgabe, die ich 1990 bei O'Reilly gekauft habe. Es gibt neuere Ausgaben, aber ich habe mich nie darum gekümmert, sie zu kaufen diese und sie sind AFAIK nur in Papierform erhältlich. Ich glaube nicht, dass sie die Gründe für die Aufteilung der Zuständigkeiten geändert haben.}

Ein Fenstersystem bedeutet, dass mehrere unabhängige Programme eine gemeinsame Ressource, den Bildschirm und Eingabegeräte teilen. Freigegebene Ressourcen können nur auf zwei Arten sicher implementiert werden:

• Die Ressource kann vom Kernel gesteuert werden, und Anwendungen rufen den Kernel auf, um darauf zuzugreifen.
• Die Ressource kann von einem dedizierten Prozess (Server) gesteuert werden, und Anwendungen wenden sich an den Server, um darauf zuzugreifen.

Natürlich wird der Zugriff auf die eigentliche Anzeigehardware vom Kernel gesteuert, aber das reicht für ein Fenstersystem nicht aus: Es muss eine Möglichkeit geben, einem Prozess einen bestimmten Teil der Anzeige (das Fenster) zuzuweisen, in dem dies sinnvoll sein kann Stellen Sie sicher, dass kein anderer Prozess stört, und es muss ein gewisses Maß an Schutz dafür bestehen, welche Anwendung zu welchem ​​Zeitpunkt auf welchen Teil der Ressource zugreifen kann.

Jetzt hätte das Ganze in den Kernel gehen können, was AFAIK ist, was Windows macht. Dies hat den Vorteil, dass es schneller ist (normalerweise ist das Aufrufen des Kernels viel schneller als das Kontaktieren eines anderen Prozesses), es hat jedoch den Nachteil, dass möglicherweise Sicherheitslücken entstehen (jeder Exploit des Systems ist ein Exploit auf Kernel-Ebene) und dasselbe Zeit schränkt die Portabilität ein (ein im Kernel implementiertes System ist stark an den Kernel gekoppelt; Sie können es nicht einfach auf ein anderes Betriebssystem portieren, und Sie können es überhaupt nicht tun, wenn Sie keinen Zugriff auf den Kernel-Code haben).

Wenn Sie es nicht im Kernel implementieren möchten, können Sie es nur als dedizierten Prozess implementieren, dh als Server. Beachten Sie, dass ein Server, der über Named Pipes kontaktiert wird, immer noch ein Server ist. Außerdem geschieht heutzutage ein Großteil der Kommunikation zwischen dem X-Server und den Clients auf demselben Computer über den gemeinsamen Speicher. Das ändert jedoch nichts an der Tatsache, dass der Anzeigeserver ein Server ist.

Warum wird der Server nun über Sockets und nicht über Named Pipes kontaktiert? Wenn Sie Sockets verwenden, benötigen Sie nur einen Socket für den gesamten Server, der die gesamte Kommunikation ausführen kann. Wenn Sie mit Pipes kommunizieren, benötigen Sie zwei Pipes pro Client. Abgesehen von der Tatsache, dass das Verwalten all dieser Pipes ziemlich mühsam wäre, könnten Sie auch einige Betriebssystemgrenzen für die Anzahl offener Pipes erreichen, wenn genügend viele Programme gleichzeitig versuchen, mit dem Server zu kommunizieren.

Ein weiterer Vorteil von Sockets gegenüber Pipes ist natürlich, dass Sie mit Sockets Verbindungen über mehrere Computer hinweg herstellen können. Dies war besonders wichtig, wenn der eigentliche Computer von vielen Personen auf dedizierten Terminals gemeinsam genutzt wurde und die Programme auf dem Computer kommunizieren mussten zu den verschiedenen Terminals, aber es ist immer noch sehr nützlich, auch heute in vernetzten Umgebungen.

X wurde ursprünglich vom MIT entwickelt und gewartet. Und es war eine Open-Source-MIT-Lizenz, nicht das, was wirklich zählt.

Betrachten Sie einen Moment, obwohl dies als unkonventionell angesehen wird. Wie würden Sie die Entscheidung für die Verwendung eines Client-Server-Paradigmas in einer Software erklären? Und vielleicht sollte ich zu einem CEO sagen ..

So lernte ich die Wahl im College zu schätzen. In Client-Server verwaltet der Server die Ressourcen, und vor allem , alle Ressourcen , die müssen werden gemeinsam genutzt . Der X-Server ist also der Prozess, der die Client- Apps, die Tastatur, die Maus und den Framebuffer ausliefert (oder, wie auch immer Sie auf den Bildschirm Ihres Systems schreiben).

Obwohl nicht wirklich korrekt, wird der Fenstermanager oft wie folgt erklärt: Es ist einfach das Ding, das Griffe und andere Dekorationen auf den Rahmen einer App und auf Fenster, Dialoge usw. legt.

Client-Server-Modelle sind ein beliebtes Design für alle Arten von Anwendungen, auch wenn es nur einen Server und nur einen Client gibt. Sie ermöglichen eine saubere, klar definierte Schnittstelle zwischen Verantwortungsbereichen.

Es gibt viele Möglichkeiten, wie ein Server und ein Client kommunizieren können, aber die von X(ungeachtet der von anderen genannten Vorteile) getroffene Auswahl ist nicht überflüssig: Sie können eine Verbindung zu einem XServer auf einem anderen Computer herstellen und Fenster auf Ihrem Desktop (oder auf einem anderen kooperierenden Computer) öffnen Desktop). Dies war in den Tagen, als X entwickelt wurde, sehr verbreitet, als viele Universitäten und Unternehmen einen Unix-Server und viele "X-Terminals" hatten, die mit ihm sprachen. Durch die Verwendung eines internetfähigen Kommunikationsprotokolls kann X nahtlos auf oder zwischen Hosts verwendet werden.

X war die erste GUI-Umgebung, in der Fenster von einem anderen Computer transparent angezeigt werden konnten, was mit der Historie von UNIX als Mehrbenutzerumgebung und nicht als Betriebssystem für einen einzelnen Benutzer auf einem einzelnen Computer vereinbar ist. Viele UNIX-Funktionen scheinen zu viel zu sein, wenn Sie die einzige Person sind, die jemals (physisch oder remote) mit Ihrem Computer interagieren kann.

Ich glaube, der X-Server wurde als Client-Server-Architektur konzipiert, da anfangs die Rechenressourcen knapp waren und Großrechner den größten Teil der Last auf sich nahmen. X-Terminals waren lediglich Thin Clients, die eine Verbindung zu X-Servern herstellten und alles anzeigten, was dem Benutzer angezeigt werden musste.

Es hat viele Vorteile (auch wenn das Kommunikationsprotokoll für X heutzutage sehr umfangreich ist), insbesondere können Sie die gleiche Anzeige auf mehreren Clients anzeigen. In X ist es einfach, einen Bildschirm mit mehreren Benutzern zu teilen.