¿Por qué el sistema X Window utiliza un servidor?

Nunca entendí realmente por qué un sistema de ventanas debe tener un servidor. ¿Por qué los entornos de escritorio, los administradores de pantallas y los administradores de ventanas necesitan xorg-server? ¿Es solo para tener una capa de abstracción en la parte superior de la tarjeta gráfica? ¿Por qué los sistemas de ventanas emplean un modelo cliente-servidor? ¿No sería más simple la comunicación entre procesos a través de tuberías con nombre?

Creo que ya has notado que se necesita algún tipo de "servidor". Cada cliente (entorno de escritorio, administrador de ventanas o programa en ventanas) necesita compartir la pantalla con todos los demás, y deben 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 mencionó, al proporcionar una interfaz IPC.

Probablemente se pueda hacer que X11 pase por encima de las tuberías con nombre, pero hay dos cosas importantes que las tuberías con nombre no pueden hacer.

• Las tuberías con nombre solo se comunican en una dirección.
• Si dos procesos comienzan a colocar datos en el extremo de "envío" de una tubería con nombre, los datos se mezclarán.

De hecho, la mayoría de los clientes X hablan con el servidor utilizando una canalización con nombre "nueva y mejorada" llamada socket de dominio UNIX. Es muy parecido a una tubería con nombre, excepto que permite que los procesos hablen en ambas direcciones y realiza un seguimiento de quién dijo qué. Estos son los mismos tipos de cosas que la red tiene que hacer, por lo que los sockets de dominio UNIX usan la misma interfaz de programación que los sockets TCP / IP que proporcionan comunicaciones de red.

Pero a partir de ahí, es realmente fácil decir "¿Qué pasa si ejecuté el servidor en un host diferente al cliente?" Simplemente use un zócalo TCP en lugar del zócalo UNIX y listo: un protocolo de escritorio remoto que precede a Windows RDP por décadas. Puedo sshejecutar cuatro hosts remotos diferentes y ejecutar synaptic(administrador de paquetes gráfico) en cada uno de ellos, y las cuatro ventanas aparecen en la pantalla de mi computadora local.

Un sistema de ventanas no tiene que tener un servidor, pero puede 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 necesitan ejecutarse en la misma máquina y es más fácil atender a varios clientes. Actualmente, esto todavía es muy útil (por ejemplo, cuando te encuentras sshen otra máquina), pero debes darte cuenta de que en el momento en que se desarrolló X, eso se veía como una necesidad: tu máquina local podría no ser lo suficientemente potente como para ejecutar el cliente.

Las canalizaciones con nombre no le darían la ventaja automática de poder ejecutar en 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 que un cliente se ejecute en VAX / VMS (el desarrollo de X comenzó en 1984) y sirva la salida a su estación de trabajo de gráficos basada en UNIX local. Del "Sistema X Window: la referencia completa a Xlib, X Protocol, ICCCM, XLFD" ¹:

Durante el otoño de 1986, Digital decidió basar toda su estrategia de estación de trabajo de escritorio para ULTRIX, VMS y MS-DOS en X. Aunque esto fue gratificante para nosotros, también significaba que teníamos aún más personas con quienes hablar. Esto resultó en algún retraso, pero, al final, también resultó en 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. El último lanzamiento de la 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 transmitirse de un lado a otro a través de solicitudes, respuestas y eventos. Una excelente fuente de información sobre la razón detrás de ciertas elecciones realizadas al diseñar el 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 de 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.

Primero, el servidor está diseñado, tanto como sea posible, para ocultar las diferencias en el hardware subyacente de las aplicaciones del cliente. ...

Recuerdo que el artículo en TOG es una lectura interesante. Ciertamente, provocó mi interés en X y (esto fue antes de WorldWideWeb) la dificultad que tuvimos para obtener más información hasta que O'Reilly comenzó a publicar sus libros de la serie X.

¹ _{X Versión 11, Release 4, página 2-X, PDF disponible en línea aquí}
² _{Esto es de la página 9 en la 2da edición, publicada por O'Reilly, que compré en 1990. Hay ediciones más nuevas pero nunca me molesté en comprar estos y AFAIK solo están disponibles en papel también. No creo que hayan cambiado la lógica de la división de responsabilidades.}

Un sistema de ventanas significa que varios programas independientes comparten un recurso común, la pantalla y los dispositivos de entrada. Los recursos compartidos solo se pueden implementar de manera segura de dos maneras:

• El recurso puede ser controlado por el núcleo, y las aplicaciones hacen llamadas al núcleo para acceder a él.
• El recurso puede ser controlado por un proceso dedicado (servidor), y las aplicaciones contactan al servidor para acceder a él.

Por supuesto, el kernel controla el acceso al hardware real de la pantalla, pero eso no es suficiente para un sistema de ventanas: debe haber una forma para que un proceso se asigne una cierta parte de la pantalla (la ventana) donde puede ser razonablemente asegúrese de que ningún otro proceso interfiera, y debe haber un cierto nivel de protección de qué aplicación puede acceder a qué parte del recurso en qué momento.

Ahora todo podría haber entrado en el núcleo, que es AFAIK lo que hace Windows. Esto tiene la ventaja de ser más rápido (por lo general, llamar al núcleo es mucho más rápido que ponerse en contacto con otro proceso), sin embargo, tiene la desventaja de posiblemente abrir agujeros de seguridad (cualquier vulnerabilidad del sistema es una vulnerabilidad a nivel del núcleo), y al mismo tiempo 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 no podrá hacerlo por completo 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 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 ocurre 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, ¿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 puede hacer toda la comunicación. Si se comunica con tuberías, necesita dos tuberías por cliente. Además 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 suficientes programas 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 puede tener conexiones entre máquinas, lo cual fue especialmente importante en un momento en 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 todavía es muy útil incluso hoy en entornos en red.

X fue originalmente, desarrollado y mantenido por MIT. Y fue con una licencia de código abierto de MIT, y eso no es lo que realmente importa.

Si bien se considera poco convencional, considérelo por un momento; ¿Cómo explicaría la opción de utilizar un paradigma cliente-servidor en una pieza de software? Y, tal vez debería decirle a un CEO ..

Así es como aprendí a apreciar la elección en la universidad. En cliente-servidor, el servidor gestiona los recursos, y en especial , cualquier recurso que debe ser compartida . Entonces, el servidor X es el proceso que sirve, a las aplicaciones del cliente , el teclado, el mouse y el framebuffer (o, sin embargo, usted escribe en la pantalla de su sistema).

Si bien no es realmente correcto, el administrador de ventanas a menudo se explica de la siguiente manera: es simplemente eso, lo que pone manijas y otras decoraciones en el marco de una aplicación, ventanas, diálogos, etc.

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 formas en que un servidor y un cliente pueden comunicarse, la elección realizada X(independientemente de las ventajas mencionadas por otros) no es superflua: puede conectarse a un Xservidor en una máquina diferente y abrir ventanas en su escritorio (o en otro escritorio). Esto solía ser muy común en los días en que se desarrolló X, cuando muchas universidades y empresas tendrían un servidor Unix y muchos "terminales X" que hablaban con él. Mediante el uso de un protocolo de comunicaciones listo para Internet, X se puede usar sin problemas dentro de los hosts o entre ellos.

X fue el primer entorno de GUI que podía mostrar ventanas de forma transparente desde otra máquina, de acuerdo con la historia de UNIX como un entorno multiusuario en lugar de un sistema operativo para un solo usuario en una sola computadora. Muchas de las características de UNIX parecen exageradas si eres la única persona que puede interactuar (física o remotamente) con tu computadora.

Creo que el x-server fue diseñado como una arquitectura cliente-servidor porque inicialmente los recursos informáticos eran escasos y los mainframes hicieron la mayor parte del trabajo pesado. Los terminales X eran solo clientes ligeros que se conectaban a servidores x y mostraban lo que era necesario mostrar al usuario.

Tiene muchos beneficios (aunque el protocolo de comunicación para X es muy pesado hoy en día), en particular puede mostrar la misma pantalla en múltiples clientes, compartir una pantalla con múltiples usuarios es fácil en X.