Pourquoi le système X Window utilise-t-il un serveur?

Je n'ai jamais vraiment compris pourquoi un système de fenêtres doit avoir un serveur. Pourquoi les environnements de bureau, les gestionnaires d'affichage et les gestionnaires de fenêtres ont-ils besoin de xorg-server? Est-ce uniquement pour avoir une couche d'abstraction sur le dessus de la carte graphique? Pourquoi les systèmes de fenêtres utilisent-ils un modèle client-serveur? La communication interprocessus via des canaux nommés ne serait-elle pas plus simple?

Je pense que vous avez déjà remarqué qu'une sorte de "serveur" est nécessaire. Chaque client (environnement de bureau, gestionnaire de fenêtres ou programme fenêtré) doit partager l'affichage avec tous les autres, et il doit être capable d'afficher des éléments sans connaître les détails du matériel ou savoir qui d'autre utilise l'écran. Le serveur X11 fournit donc la couche d'abstraction et de partage que vous avez mentionnée, en fournissant une interface IPC.

X11 pourrait probablement être conçu pour fonctionner sur des canaux nommés, mais il y a deux grandes choses que les canaux nommés ne peuvent pas faire.

• Les canaux nommés ne communiquent que dans une seule direction.
• Si deux processus commencent à mettre des données dans l'extrémité "d'envoi" d'un canal nommé, les données seront mélangées.

En fait, la plupart des clients X parlent au serveur à l'aide d'un canal nommé "nouveau et amélioré" appelé socket de domaine UNIX. Cela ressemble beaucoup à un canal nommé, sauf qu'il permet aux processus de parler dans les deux sens et qu'il garde la trace de qui a dit quoi. Ce sont les mêmes choses que le réseau doit faire, et donc les sockets de domaine UNIX utilisent la même interface de programmation que les sockets TCP / IP qui assurent les communications réseau.

Mais à partir de là, il est vraiment facile de dire "Et si j'exécutais le serveur sur un hôte différent du client?" Utilisez simplement un socket TCP au lieu du socket UNIX, et le tour est joué: un protocole de bureau à distance qui précède Windows RDP de plusieurs décennies. Je peux accéder sshà quatre hôtes distants différents et les exécuter synaptic(gestionnaire de packages graphiques) sur chacun d'eux, et les quatre fenêtres apparaissent sur l'écran de mon ordinateur local.

Un système de fenêtres ne doit pas nécessairement avoir de serveur, mais vous pouvez décider de mettre en œuvre un système de fenêtres basé sur un modèle client-serveur. Cela présente plusieurs avantages, car vous séparez clairement les activités du client et du serveur, elles n'ont pas besoin de s'exécuter sur la même machine et il est plus facile de desservir plusieurs clients. C'est actuellement encore très pratique (par exemple lorsque vous entrez sshdans une autre machine), mais vous devez vous rendre compte qu'au moment où X a été développé, cela était considéré comme une nécessité: votre machine locale n'était peut-être pas assez puissante pour exécuter le client.

Les canaux nommés ne vous donneraient pas automatiquement l'avantage de pouvoir s'exécuter sur le réseau comme le ferait une implémentation TCP. Mais les canaux nommés n'étaient par exemple pas disponibles sous DOS, DosExtender exécutant Desqview / X (1992), et AFAIK non plus sur VMS. Pour ces implémentations, une communication spécifique à Unix serait un problème.

TCP n'est pas spécifique à Unix et il est possible d'avoir un client exécuté sous VAX / VMS (le développement X a commencé en 1984) et de servir la sortie à votre station de travail graphique basée sur UNIX locale. Extrait du "Système X Window: la référence complète à Xlib, X Protocol, ICCCM, XLFD" ¹:

Au cours de l'automne 1986, Digital a décidé de baser toute sa stratégie de poste de travail de bureau pour ULTRIX, VMS et MS-DOS sur X. Bien que cela nous soit gratifiant, cela signifiait également que nous avions encore plus de personnes à qui parler. Cela a entraîné un certain retard, mais au final, cela a également entraîné une meilleure conception. Ralph Swick de Digital a rejoint Project Athena pendant cette période et a joué un rôle essentiel tout au long du développement de la version 11. La dernière version 10 a été mise à disposition en décembre 1986.

Du "Manuel de référence du protocole X" ²:

Répartition des responsabilités

Dans le processus de conception du protocole X, une grande attention a été accordée à la division des capacités entre le serveur et le client, car cela détermine quelles informations doivent être transmises dans les deux sens via les demandes, les réponses et les événements. Une excellente source d'informations sur la justification de certains choix faits dans la conception du protocole est l'article The X Window System, par Robert W. Scheifler et Jim Gettys, publié dans la revue Transaction on Graphics de l'Association of Computing Machinery, Vol 5, No. 2, avril 1986 Les décisions finalement prises étaient fondées sur la portabilité des programmes clients, la facilité de programmation client et les performances.

Premièrement, le serveur est conçu, autant que possible, pour cacher les différences dans le matériel sous-jacent des applications clientes. ...

Je me souviens que l'article de TOG était une lecture intéressante. Cela a certainement déclenché mon intérêt pour X et (c'était avant WorldWideWeb) la difficulté que nous avions à mettre la main sur plus d'informations jusqu'à ce qu'O'Reilly commence à publier leurs livres de la série X.

¹ _{X Version 11, Release 4, page 2-X, PDF disponible en ligne ici}
² _{Ceci est de la page 9 de la 2e édition, publiée par O'Reilly, que j'ai achetée en 1990. Il y a des éditions plus récentes mais je n'ai jamais pris la peine d'acheter ceux-ci et ils sont AFAIK uniquement disponibles en papier également. Je ne pense pas qu'ils aient changé la raison d'être du partage des responsabilités.}

Un système de fenêtrage signifie que plusieurs programmes indépendants partagent une ressource commune, l'écran et les périphériques d'entrée. Les ressources partagées ne peuvent être mises en œuvre en toute sécurité que de deux manières:

• La ressource peut être contrôlée par le noyau et les applications effectuent des appels au noyau pour y accéder.
• La ressource peut être contrôlée par un processus dédié (serveur) et les applications contactent le serveur pour y accéder.

Bien sûr, l'accès au matériel d'affichage réel est contrôlé par le noyau, mais ce n'est pas suffisant pour un système de fenêtrage: il doit y avoir un moyen pour qu'un processus se voit attribuer une certaine partie de l'affichage (la fenêtre) où il peut être raisonnablement assurez-vous qu'aucun autre processus n'interfère, et il doit y avoir un certain niveau de protection de quelle application peut accéder à quelle partie de la ressource à quel moment.

Maintenant, le tout aurait pu aller dans le noyau, ce qui est AFAIK ce que fait Windows. Cela a l'avantage d'être plus rapide (généralement appeler le noyau est beaucoup plus rapide que de contacter un autre processus), mais il a l'inconvénient d'ouvrir éventuellement des failles de sécurité (tout exploit du système est un exploit au niveau du noyau), et en même temps le temps limite la portabilité (un système implémenté dans le noyau est fortement couplé au noyau; vous ne pourrez pas le porter facilement vers un autre système d'exploitation, et complètement incapable de le faire si vous n'avez pas accès au code du noyau).

Si vous ne voulez pas l'implémenter dans le noyau, la seule autre façon de l'implémenter est comme un processus dédié, c'est-à-dire un serveur. Notez qu'un serveur qui est contacté via des canaux nommés est toujours un serveur. De plus, lors de l'exécution sur la même machine, une grande partie de la communication entre le serveur X et les clients se fait via la mémoire partagée de nos jours; cela ne change toujours pas le fait que le serveur d'affichage est un serveur.

Maintenant, pourquoi le serveur est-il contacté à l'aide de sockets et non à l'aide de canaux nommés? Eh bien, si vous le faites à l'aide de sockets, il vous suffit d'avoir un socket pour l'ensemble du serveur, qui peut effectuer toutes les communications. Si vous communiquez avec des canaux, vous avez besoin de deux canaux par client. Outre le fait que la gestion de tous ces canaux serait assez lourde, vous pouvez également atteindre certaines limites du système d'exploitation sur le nombre de canaux ouverts si suffisamment de programmes essaient de parler au serveur en même temps.

Et bien sûr, un autre avantage des sockets sur les tuyaux est qu'avec les sockets, vous pouvez avoir des connexions entre machines, ce qui était particulièrement important à un moment où l'ordinateur réel était partagé par de nombreuses personnes assises sur des terminaux dédiés, de sorte que les programmes sur l'ordinateur devaient communiquer aux différents terminaux, mais il est encore très utile même aujourd'hui dans les environnements en réseau.

X était à l'origine, développé et maintenu par le MIT Et, c'était avec une licence open source MIT, ce n'est pas vraiment ce qui compte.

Bien que considéré comme non conventionnel, réfléchissez un instant; comment expliqueriez-vous le choix d'utiliser un paradigme client-serveur dans un logiciel? Et, je devrais peut-être dire à un PDG ..

Voici comment j'ai appris à apprécier le choix au collège. En client-serveur, le serveur gère les ressources, et surtout , toutes les ressources qui doivent être partagées . Ainsi, le serveur X est le processus qui sert aux applications clientes , au clavier, à la souris et au tampon d'image (ou, cependant, vous écrivez à l'écran de votre système).

Bien qu'il ne soit pas vraiment correct, le gestionnaire de fenêtres est souvent expliqué comme suit: c'est simplement cette chose qui met des poignées et d'autres décorations sur le cadre d'une application, et des fenêtres, des boîtes de dialogue, etc.

Les modèles client-serveur sont une conception populaire pour toutes sortes d'applications, même lorsqu'il n'y a qu'un seul serveur et un seul client. Ils permettent une interface claire et bien définie entre les domaines de responsabilité.

Bien qu'il existe de nombreuses façons pour un serveur et un client de communiquer, le choix fait par X(indépendamment des avantages mentionnés par d'autres) n'est pas superflu: vous pouvez vous connecter à un Xserveur sur une autre machine et ouvrir des fenêtres sur votre bureau (ou sur une autre coopérante). bureau). Cela était très courant à l'époque où X a été développé, lorsque de nombreuses universités et entreprises disposaient d'un serveur Unix et de nombreux "terminaux X" qui lui parlaient. En utilisant un protocole de communication prêt pour Internet, X peut être utilisé de manière transparente au sein ou entre les hôtes.

X était le premier environnement GUI qui pouvait afficher de manière transparente les fenêtres d'une autre machine, cohérent avec l'histoire d'UNIX en tant qu'environnement multi-utilisateurs plutôt que comme OS pour un seul utilisateur sur un seul ordinateur. De nombreuses fonctionnalités UNIX semblent exagérées si vous êtes la seule personne à pouvoir interagir (physiquement ou à distance) avec votre ordinateur.

Je crois que le x-server a été conçu comme une architecture client-serveur car au départ, les ressources informatiques étaient rares et les mainframes faisaient la plupart des tâches lourdes. Les terminaux X n'étaient que des clients légers qui se connectaient aux serveurs X et affichaient tout ce qui devait être affiché pour l'utilisateur.

Il présente de nombreux avantages (bien que le protocole de communication pour X soit très lourd de nos jours), notamment vous pouvez afficher le même affichage sur plusieurs clients, partager un écran avec plusieurs utilisateurs est facile dans X.