Nunca entendí realmente por qué un sistema de ventanas debe tener un servidor. ¿Por qué los entornos de escritorio, administradores de visualización y administradores de ventanas necesitan xorg-server? ¿Es sólo para tener una capa de abstracción encima de la tarjeta gráfica? ¿Por qué los sistemas de ventanas emplean un modelo cliente-servidor? ¿No sería más sencilla la comunicación entre procesos a través de canalizaciones con nombre?
Respuesta1
Creo que ya habrás notado que se necesita algún tipo de "servidor". Cada cliente (entorno de escritorio, administrador de ventanas o programa de ventanas) necesita compartir la pantalla con todos los demás y debe poder mostrar cosas sin conocer los detalles del hardware o saber quién más está usando la pantalla. Entonces, el servidor X11 proporciona la capa de abstracción y uso compartido que usted mencionó, al proporcionar una interfaz IPC.
Probablemente se podría hacer que X11 funcione sobre canalizaciones con nombre, pero hay dos cosas importantes que las canalizaciones con nombre no pueden hacer.
- Las canalizaciones con nombre solo se comunican en una dirección.
- Si dos procesos comienzan a colocar datos en el extremo de "envío" de una canalización con nombre, los datos se mezclarán.
De hecho, la mayoría de los clientes X se comunican con el servidor utilizando una tubería con nombre "nueva y mejorada" llamada socket de dominio UNIX. Es muy parecido a una canalización con nombre, excepto que permite que los procesos hablen en ambas direcciones y realiza un seguimiento de quién dijo qué. Estos son el mismo tipo de cosas que la red tiene que hacer, por lo que los sockets de dominio UNIX utilizan la misma interfaz de programación que los sockets TCP/IP que proporcionan comunicaciones de red.
Pero a partir de ahí, es muy fácil decir "¿Qué pasa si ejecuto el servidor en un host diferente al del cliente?" Simplemente use un socket TCP en lugar del socket UNIX, y listo: un protocolo de escritorio remoto que es anterior al RDP de Windows por décadas. Puedo sshconectarme a cuatro hosts remotos diferentes y ejecutar synaptic(administrador gráfico de paquetes) en cada uno de ellos, y las cuatro ventanas aparecen en la pantalla de mi computadora local.
Respuesta2
Un sistema de ventanas no tiene por qué tener un servidor, pero puedes decidir implementar un sistema de ventanas basado en un modelo cliente-servidor. Hacerlo tiene varias ventajas, ya que separa claramente las actividades en el cliente y el servidor, no es necesario que se ejecuten en la misma máquina y es más fácil atender a varios clientes. Actualmente, esto sigue siendo muy útil (por ejemplo, cuando ingresa ssha otra máquina), pero debe darse cuenta de que en el momento en que se desarrolló X, eso se consideraba una necesidad: su máquina local podría no ser lo suficientemente potente para ejecutar el cliente.
Las canalizaciones con nombre no le brindarían la ventaja automática de poder ejecutarse a través de la red como lo haría una implementación de TCP. Pero las canalizaciones con nombre, por ejemplo, no estaban disponibles en DOS, con DosExtender ejecutando Desqview/X (1992) y AFAIK tampoco en VMS. Para esas implementaciones, una comunicación específica de Unix sería un problema.
TCP no es específico de Unix y es posible ejecutar un cliente bajo VAX/VMS (el desarrollo de X comenzó en 1984) y servir la salida a su estación de trabajo de gráficos local basada en UNIX. Del "Sistema X Window: la referencia completa a Xlib, protocolo X, ICCCM, XLFD"¹:
Durante el otoño de 1986, Digital decidió basar toda su estrategia de estaciones de trabajo de escritorio para ULTRIX, VMS y MS-DOS en X. Aunque esto fue gratificante para nosotros, también significó que teníamos aún más gente con quien hablar. Esto provocó cierto retraso, pero al final también dio lugar a un mejor diseño. Ralph Swick de Digital se unió al Proyecto Athena durante este período y jugó un papel vital durante el desarrollo de la versión 11. La última versión 10 estuvo disponible en diciembre de 1986.
Del "Manual de referencia del protocolo X"²:
División de responsabilidades
En el proceso de diseño del protocolo X, se pensó mucho en la división de capacidades entre el servidor y el cliente, ya que esto determina qué información debe pasarse de un lado a otro a través de solicitudes, respuestas y eventos. Una excelente fuente de información sobre el fundamento detrás de ciertas decisiones tomadas en el diseño del protocolo es el artículo The X Window System, de Robert W. Scheifler y Jim Gettys, publicado en la revista Transaction on Graphics de la Association of Computing Machinery, Vol 5, No. 2, abril de 1986 Las decisiones finalmente tomadas se basaron en la portabilidad de los programas del cliente, la facilidad de programación del cliente y el rendimiento.
En primer lugar, el servidor está diseñado, en la medida de lo posible, para ocultar las diferencias en el hardware subyacente de las aplicaciones cliente. ...
Recuerdo que el artículo de TOG fue una lectura interesante. Ciertamente despertó mi interés en X y (esto fue antes de la WorldWideWeb) la dificultad que tuvimos para conseguir más información hasta que O'Reilly comenzó a publicar sus libros de la serie X.
¹ X Versión 11, Versión 4, página 2-X, PDF disponible en líneaaquí
² Esto es de la página 9 de la segunda edición, publicada por O'Reilly, que compré en 1990. Hay ediciones más nuevas, pero nunca me molesté en comprarlas y, AFAIK, solo están disponibles en papel. No creo que hayan cambiado la lógica de la división de responsabilidades.
Respuesta3
Un sistema de ventanas significa que varios programas independientes comparten un recurso común, la pantalla y los dispositivos de entrada. Los recursos compartidos sólo se pueden implementar de forma segura de dos maneras:
- El recurso puede estar controlado por el kernel y las aplicaciones realizan llamadas al kernel para acceder a él.
- El recurso puede estar controlado por un proceso dedicado (servidor) y las aplicaciones contactan al servidor para acceder a él.
Por supuesto, el acceso al hardware de visualización real está controlado por el kernel, pero eso no es suficiente para un sistema de ventanas: debe haber una manera para que a un proceso se le asigne un determinadopartede la pantalla (la ventana) donde se puede estar razonablemente seguro de que ningún otro proceso interferirá, y debe haber un cierto nivel de protección de qué aplicación puede acceder a qué parte del recurso y en qué momento.
Ahora todo podría haber ido al kernel, que es, AFAIK, lo que hace Windows. Esto tiene la ventaja de ser más rápido (normalmente llamar al kernel es mucho más rápido que contactar con otro proceso), sin embargo, tiene la desventaja de posiblemente abrir agujeros de seguridad (cualquier exploit del sistema es un exploit a nivel del kernel), y al mismo El tiempo restringe la portabilidad (un sistema implementado en el kernel está fuertemente acoplado al kernel; no podrá portarlo fácilmente a otro sistema operativo, y es completamente imposible hacerlo si no tiene acceso al código del kernel).
Si no desea implementarlo en el kernel, la única otra forma de implementarlo es como un proceso dedicado, es decir, un servidor. Tenga en cuenta que un servidor con el que se contacta a través de canalizaciones con nombre sigue siendo un servidor. Además, cuando se ejecuta en la misma máquina, gran parte de la comunicación entre el servidor X y los clientes se realiza a través de la memoria compartida en estos días; eso todavía no cambia el hecho de que el servidor de visualización es un servidor.
Ahora bien, ¿por qué se contacta al servidor mediante sockets y no mediante canalizaciones con nombre? Bueno, si lo haces usando sockets, solo necesitas tener un socket para todo el servidor, que pueda realizar toda la comunicación. Si se comunica con tuberías, necesita dos tuberías por cliente. Aparte del hecho de que administrar todas esas tuberías sería bastante engorroso, también podría alcanzar algunos límites del sistema operativo en la cantidad de tuberías abiertas si hay suficientes programas que intentan comunicarse con el servidor al mismo tiempo.
Y, por supuesto, otra ventaja de los enchufes sobre las tuberías es que con los enchufes se pueden tener conexiones entre máquinas, lo cual era especialmente importante en una época en la que la computadora real era compartida por muchas personas sentadas en terminales dedicadas, por lo que los programas en la computadora tenían que comunicarse. a los diferentes terminales, pero sigue siendo muy útil incluso hoy en día en entornos de red.
Respuesta4
Los modelos cliente-servidor son un diseño popular para todo tipo de aplicaciones, incluso cuando solo hay un servidor y un solo cliente. Permiten una interfaz limpia y bien definida entre dominios de responsabilidad.
Si bien hay muchas maneras en que un servidor y un cliente pueden comunicarse, la elección hecha por X(independientemente de las ventajas mencionadas por otros) no es superflua: ustedpoderconéctese a un Xservidor en una máquina diferente y abra ventanas en su escritorio (o en otro escritorio cooperante). Esto solía ser muy común en los días en que se desarrolló X, cuando muchas universidades y empresas tenían un servidor Unix y muchos "terminales X" que hablaban con él.Al utilizar un protocolo de comunicaciones listo para Internet, X se puede utilizar sin problemas dentro o entre hosts.
X fue el primer entorno GUI que podía mostrar ventanas de forma transparente desde otra máquina, en consonancia con la historia de UNIX como entorno multiusuario en lugar de un sistema operativo para un solo usuario en una sola computadora. Muchas funciones de UNIX parecen excesivas si eres la única persona que puede interactuar (física o remotamente) con tu computadora.