Ich habe nie wirklich verstanden, warum ein Fenstersystem einen Server haben muss. Warum benötigen Desktopumgebungen, Displaymanager und Fenstermanager einen Xorg-Server? Geht es nur darum, eine Abstraktionsschicht über der Grafikkarte zu haben? Warum verwenden Fenstersysteme ein Client-Server-Modell? Wäre die Interprozesskommunikation über benannte Pipes nicht einfacher?
Antwort1
Ich denke, Sie haben bereits bemerkt, dass eine Art „Server“ erforderlich ist. Jeder Client (Desktop-Umgebung, Fenstermanager oder Fensterprogramm) muss die Anzeige mit allen anderen teilen, und sie müssen in der Lage sein, Dinge anzuzeigen, ohne die Details der Hardware zu kennen oder zu wissen, wer sonst noch die Anzeige verwendet. Der X11-Server bietet also die von Ihnen erwähnte Abstraktions- und Freigabeebene, indem er eine IPC-Schnittstelle bereitstellt.
X11 könnte wahrscheinlich so gestaltet werden, dass es über benannte Pipes läuft, aber es gibt zwei große Dinge, die benannte Pipes nicht können.
- Named Pipes kommunizieren nur in eine Richtung.
- Wenn zwei Prozesse beginnen, Daten in das „sendende“ Ende einer benannten Pipe einzufügen, vermischen sich die Daten.
Tatsächlich kommunizieren die meisten X-Clients mit dem Server über eine „neue und verbesserte“ benannte Pipe, die als UNIX-Domain-Socket bezeichnet wird. Sie ähnelt einer benannten Pipe sehr, lässt jedoch Prozesse in beide Richtungen kommunizieren und verfolgt, wer was gesagt hat. Dies sind die gleichen Dinge, die das Netzwerk tun muss, und daher verwenden UNIX-Domain-Sockets dieselbe Programmierschnittstelle wie die TCP/IP-Sockets, die die Netzwerkkommunikation ermöglichen.
Aber von da an ist es ganz einfach zu sagen: „Was wäre, wenn ich den Server auf einem anderen Host laufen lassen würde als den Client?“ Verwenden Sie einfach einen TCP-Socket anstelle des UNIX-Sockets und voilà: ein Remote-Desktop-Protokoll, das Jahrzehnte älter ist als Windows RDP. Ich kann sshauf vier verschiedene Remote-Hosts zugreifen und (den grafischen Paketmanager) auf jedem von ihnen ausführen synaptic, und alle vier Fenster erscheinen auf dem Display meines lokalen Computers.
Antwort2
Ein Fenstersystem muss keinen Server haben, aber Sie können sich entscheiden, ein Fenstersystem basierend auf einem Client-Server-Modell zu implementieren. Dies hat mehrere Vorteile, da Sie die Aktivitäten im Client und im Server klar trennen, sie nicht auf derselben Maschine ausgeführt werden müssen und es einfacher ist, mehrere Clients zu bedienen. Das ist derzeit noch sehr praktisch (z. B. wenn Sie sshin eine andere Maschine einsteigen), aber Sie müssen sich darüber im Klaren sein, dass dies zum Zeitpunkt der Entwicklung von X als Notwendigkeit angesehen wurde: Ihre lokale Maschine ist möglicherweise nicht leistungsstark genug, um den Client auszuführen.
Named Pipes würden Ihnen nicht automatisch den Vorteil bieten, über das Netzwerk laufen zu können, wie es bei einer TCP-Implementierung der Fall wäre. Aber Named Pipes waren beispielsweise unter DOS nicht verfügbar, mit DosExtender unter Desqview/X (1992) und meines Wissens 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 laufen zu lassen (die X-Entwicklung begann 1984) und die Ausgabe an Ihre lokale UNIX-basierte Grafik-Workstation zu liefern. Aus dem „X Window System: The Complete Reference to Xlib, X Protocol, ICCCM, XLFD“¹:
Im Herbst 1986 beschloss Digital, seine gesamte Desktop-Workstation-Strategie für ULTRIX, VMS und MS-DOS auf X aufzubauen. Obwohl das für uns erfreulich war, bedeutete es auch, dass wir mit noch mehr Leuten sprechen mussten. Dies führte zu einigen Verzögerungen, führte aber letztendlich 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“²:
Aufgabenverteilung
Bei der Entwicklung des X-Protokolls wurde viel über die Aufteilung der Fähigkeiten zwischen Server und Client nachgedacht, da diese bestimmt, welche Informationen über Anfragen, Antworten und Ereignisse hin und her übermittelt werden müssen. Eine ausgezeichnete Informationsquelle über die Gründe für bestimmte Entscheidungen bei der Entwicklung des Protokolls ist der Artikel The X Window System von Robert W. Scheifler und Jim Gettys, der im Journal Transaction on Graphics der Association of Computing Machinery, Vol. 5, Nr. 2, April 1986, veröffentlicht wurde. 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 vor Client-Anwendungen möglichst verborgen bleiben. ...
Ich erinnere mich, dass der Artikel in TOG eine interessante Lektüre war. Er weckte definitiv mein Interesse an X und (das war vor dem World Wide Web) die Schwierigkeiten, an weitere Informationen zu kommen, bis O'Reilly begann, die Bücher der Serie X zu veröffentlichen.
¹ X Version 11, Release 4, Seite 2-X, PDF online verfügbarHier
² Dies ist Seite 9 der 2. Auflage, herausgegeben von O'Reilly, die ich 1990 gekauft habe. Es gibt neuere Ausgaben, aber ich habe mir nie die Mühe gemacht, diese zu kaufen, und meines Wissens sind sie auch nur in Papierform erhältlich. Ich glaube nicht, dass sie die Logik der Aufgabenteilung geändert haben.
Antwort3
In einem Fenstersystem teilen sich mehrere unabhängige Programme eine gemeinsame Ressource: den Bildschirm und Eingabegeräte. Gemeinsam genutzte Ressourcen können nur auf zwei Arten sicher implementiert werden:
- Die Ressource kann vom Kernel gesteuert werden und Anwendungen führen Kernel-Aufrufe aus, um darauf zuzugreifen.
- Die Ressource kann von einem dedizierten Prozess (Server) gesteuert werden und Anwendungen kontaktieren 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 eine bestimmteTeilder Anzeige (des Fensters), wo einigermaßen sicher sein kann, dass kein anderer Prozess eingreift, und es muss ein gewisses Maß an Schutz darüber bestehen, welche Anwendung zu welchem Zeitpunkt auf welchen Teil der Ressource zugreifen kann.
Nun hätte das Ganze in den Kernel gehen können, was meines Wissens nach auch Windows tut. Das hat den Vorteil, dass es schneller ist (normalerweise ist der Aufruf des Kernels viel schneller als die Kontaktaufnahme mit einem anderen Prozess), hat jedoch den Nachteil, dass möglicherweise Sicherheitslücken entstehen (jeder Exploit des Systems ist ein Exploit auf Kernelebene) und schränkt gleichzeitig 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 das ist völlig unmöglich, wenn Sie keinen Zugriff auf den Kernelcode haben).
Wenn Sie es nicht im Kernel implementieren möchten, können Sie es nur als dedizierten Prozess, also als Server, implementieren. Beachten Sie, dass ein Server, der über benannte Pipes kontaktiert wird, immer noch ein Server ist. Außerdem erfolgt heutzutage ein Großteil der Kommunikation zwischen X-Server und Clients über gemeinsam genutzten Speicher, wenn sie auf derselben Maschine ausgeführt werden. Dies ändert jedoch nichts an der Tatsache, dass der Anzeigeserver ein Server ist.
Warum wird der Server nun über Sockets und nicht über benannte Pipes kontaktiert? Wenn Sie Sockets verwenden, benötigen Sie nur einen Socket für den gesamten Server, der die gesamte Kommunikation durchführen kann. Wenn Sie über Pipes kommunizieren, benötigen Sie zwei Pipes pro Client. Abgesehen davon, dass die Verwaltung all dieser Pipes ziemlich umständlich wäre, könnten Sie auch an einige Betriebssystemgrenzen hinsichtlich der Anzahl offener Pipes stoßen, wenn genügend viele Programme gleichzeitig versuchen, mit dem Server zu kommunizieren.
Ein weiterer Vorteil von Sockets gegenüber Pipes besteht natürlich darin, dass Sockets Verbindungen zwischen Maschinen ermöglichen. Dies war insbesondere zu einer Zeit wichtig, als der eigentliche Computer von vielen Leuten gemeinsam genutzt wurde, die an dedizierten Terminals saßen, sodass die Programme auf dem Computer mit den verschiedenen Terminals kommunizieren mussten. Aber auch heute noch ist dies in vernetzten Umgebungen sehr nützlich.
Antwort4
Client-Server-Modelle sind ein beliebtes Design für alle Arten von Anwendungen, selbst wenn es nur einen Server und nur einen Client gibt. Sie ermöglichen eine saubere, klar definierte Schnittstelle zwischen Verantwortungsbereichen.
Obwohl es viele Möglichkeiten gibt, wie ein Server und ein Client kommunizieren können, Xist die von Ihnen getroffene Wahl (ungeachtet der von anderen genannten Vorteile) nicht überflüssig: SiedürfenStellen Sie eine Verbindung zu einem XServer auf einem anderen Computer her und öffnen Sie Fenster auf Ihrem Desktop (oder auf einem anderen kooperierenden Desktop). Dies war zu der Zeit, als X entwickelt wurde, sehr üblich, als viele Universitäten und Unternehmen einen Unix-Server und viele „X-Terminals“ hatten, die mit ihm kommunizierten.Durch die Verwendung eines internetfähigen Kommunikationsprotokolls kann X nahtlos innerhalb oder zwischen Hosts verwendet werden.
X war die erste GUI-Umgebung, die Fenster von einem anderen Rechner transparent anzeigen konnte, was mit der Geschichte von UNIX als Mehrbenutzerumgebung und nicht als Betriebssystem für einen einzelnen Benutzer auf einem einzelnen Computer übereinstimmt. Viele UNIX-Funktionen erscheinen übertrieben, wenn Sie die einzige Person sind, die jemals (physisch oder remote) mit Ihrem Computer interagieren kann.