Perché il sistema X Window utilizza un server?

Non ho mai veramente capito perché un sistema a finestre debba avere un server. Perché ambienti desktop, display manager e window manager necessitano di xorg-server? È solo per avere uno strato di astrazione sulla parte superiore della scheda grafica? Perché i sistemi di finestre utilizzano un modello client-server? La comunicazione tra processi tramite named pipe non sarebbe più semplice?

Penso che tu abbia già notato che è necessaria una sorta di "server". Ogni client (ambiente desktop, gestore di finestre o programma con finestre) deve condividere il display con tutti gli altri e deve essere in grado di visualizzare le cose senza conoscere i dettagli dell'hardware o sapere chi altro sta usando il display. Quindi il server X11 fornisce il livello di astrazione e condivisione menzionato, fornendo un'interfaccia IPC.

Probabilmente X11 potrebbe essere fatto funzionare su pipe con nome, ma ci sono due grandi cose che le pipe con nome non possono fare.

• Le pipe con nome comunicano solo in una direzione.
• Se due processi iniziano a inserire i dati nell'estremità "invio" di una pipe denominata, i dati verranno mescolati.

In effetti, la maggior parte dei client X parla al server usando una pipe denominata "nuova e migliorata" chiamata socket di dominio UNIX. È molto simile a una pipa denominata, tranne per il fatto che consente ai processi di parlare in entrambe le direzioni e tiene traccia di chi ha detto cosa. Queste sono le stesse cose che la rete deve fare, quindi i socket di dominio UNIX usano la stessa interfaccia di programmazione dei socket TCP / IP che forniscono comunicazioni di rete.

Ma da lì, è davvero facile dire "E se avessi eseguito il server su un host diverso rispetto al client?" Basta usare un socket TCP invece del socket UNIX e voilà: un protocollo desktop remoto che precede Windows RDP da decenni. Posso eseguire sshquattro diversi host remoti ed eseguire synaptic(Gestione pacchetti grafici) su ciascuno di essi e tutte e quattro le finestre vengono visualizzate sul display del mio computer locale.

Un sistema a finestre non deve avere un server, ma puoi decidere di implementare un sistema a finestre basato su un modello client-server. In questo modo si ottengono numerosi vantaggi poiché si separano chiaramente le attività nel client e nel server, non è necessario eseguirle sulla stessa macchina ed è più facile eseguire la manutenzione di più client. Questo è ancora molto utile (ad es. Quando ci si trova sshin un'altra macchina), ma è necessario rendersi conto che al momento in cui X è stato sviluppato, questo è stato visto come una necessità: la macchina locale potrebbe non essere abbastanza potente per eseguire il client.

Le pipe con nome non ti darebbero il vantaggio automatico di poter funzionare sulla rete come farebbe un'implementazione TCP. Ma le pipe denominate, ad esempio, non erano disponibili su DOS, con DosExtender con Desqview / X (1992) e AFAIK non su VMS. Per tali implementazioni una comunicazione specifica per Unix sarebbe un problema.

TCP non è specifico di Unix ed è possibile far funzionare un client con VAX / VMS (lo sviluppo di X è iniziato nel 1984) e servire l'output sulla workstation grafica basata su UNIX locale. Da "X Window System: il riferimento completo a Xlib, protocollo X, ICCCM, XLFD" ¹:

Nell'autunno del 1986, Digital decise di basare la sua intera strategia di workstation desktop per ULTRIX, VMS e MS-DOS su X. Sebbene questo ci gratificasse, significava anche che avevamo ancora più persone con cui parlare. Ciò ha comportato alcuni ritardi, ma alla fine ha portato anche a un design migliore. Ralph Swick di Digital è entrato a far parte del Progetto Athena durante questo periodo e ha svolto un ruolo vitale nello sviluppo della versione 11. L'ultima versione 10 è stata resa disponibile nel dicembre 1986.

Dal "Manuale di riferimento del protocollo X" ²:

Divisione di responsabilità

Nel processo di progettazione del protocollo X, molto pensiero è andato nella divisione delle capacità tra il server e il client, ma questo determina quali informazioni devono essere trasmesse avanti e indietro attraverso richieste, risposte ed eventi. Un'eccellente fonte di informazioni sulla logica alla base di alcune scelte fatte nella progettazione del protocollo è l'articolo The X Window System, di Robert W. Scheifler e Jim Gettys, pubblicato nella rivista Association of Computing Machinery Transaction on Graphics, Vol 5, No. 2, aprile 1986 Le decisioni prese alla fine si basavano sulla portabilità dei programmi client, sulla facilità di programmazione dei client e sulle prestazioni.

Innanzitutto, il server è progettato, per quanto possibile, per nascondere le differenze nell'hardware sottostante dalle applicazioni client. ...

Ricordo che l'articolo su TOG era una lettura interessante. Ciò ha sicuramente innescato il mio interesse per X e (questo era prima del WorldWideWeb) la difficoltà che abbiamo avuto di mettere le mani su ulteriori informazioni fino a quando O'Reilly ha iniziato a pubblicare i loro libri della serie X.

¹ _{X versione 11, versione 4, pagina 2-X, PDF disponibile online qui}
² _{Questo è da pagina 9 della 2a edizione, pubblicata da O'Reilly, che ho acquistato nel 1990. Ci sono edizioni più recenti ma non mi sono mai preso la briga di acquistare questi e sono AFAIK disponibili anche solo su carta. Non penso che abbiano cambiato la logica della divisione delle responsabilità.}

Un sistema a finestre significa che diversi programmi indipendenti condividono una risorsa comune, lo schermo e i dispositivi di input. Le risorse condivise possono essere implementate in sicurezza solo in due modi:

• La risorsa può essere controllata dal kernel e le applicazioni effettuano chiamate del kernel per accedervi.
• La risorsa può essere controllata da un processo dedicato (server) e le applicazioni contattano il server per accedervi.

Naturalmente, l'accesso all'hardware di visualizzazione effettivo è controllato dal kernel, ma ciò non è sufficiente per un sistema a finestre: ci deve essere un modo per assegnare a un processo una determinata parte del display (la finestra) dove può essere ragionevolmente sicuro che nessun altro processo interferirà e che ci deve essere un certo livello di protezione di quale applicazione può accedere a quale parte della risorsa in quel momento.

Ora tutto sarebbe potuto andare nel kernel, che è AFAIK come fa Windows. Questo ha il vantaggio di essere più veloce (di solito chiamare il kernel è molto più veloce di contattare un altro processo), tuttavia ha lo svantaggio di aprire eventuali falle di sicurezza (qualsiasi exploit del sistema è un exploit a livello di kernel), e allo stesso tempo il tempo limita la portabilità (un sistema implementato nel kernel è fortemente accoppiato al kernel; non sarai in grado di portarlo facilmente su un altro sistema operativo e non potrai farlo se non hai accesso al codice del kernel).

Se non si desidera implementarlo nel kernel, l'unico altro modo per implementarlo è come un processo dedicato, ovvero un server. Si noti che un server che viene contattato tramite named pipe è ancora un server. Inoltre, quando si esegue sulla stessa macchina, al giorno d'oggi molte comunicazioni tra server X e client avvengono attraverso la memoria condivisa; che comunque non cambia il fatto che il server di visualizzazione sia un server.

Ora, perché il server viene contattato tramite socket e non utilizzando named pipe? Bene, se lo fai usando i socket, devi solo avere un socket per l'intero server, che può fare tutte le comunicazioni. Se si comunica con le pipe, sono necessarie due pipe per client. A parte il fatto che la gestione di tutte quelle pipe sarebbe piuttosto ingombrante, potresti anche incontrare alcuni limiti del sistema operativo sul numero di pipe aperte se un numero sufficiente di programmi tenta di parlare con il server contemporaneamente.

E ovviamente un altro vantaggio delle prese sui tubi è che con le prese è possibile avere connessioni tra le macchine, il che era particolarmente importante in un momento in cui il computer reale era condiviso da molte persone sedute su terminali dedicati, quindi i programmi sul computer dovevano comunicare ai diversi terminali, ma è ancora molto utile anche oggi in ambienti di rete.

X è stato originariamente sviluppato e gestito dal MIT ed era con una licenza MIT open source, non che, davvero, conta.

Mentre visto come non intenzionale, considera per un momento; come spiegheresti una scelta di usare un paradigma client-server in un software? E forse dovrei dire a un CEO ..

Ecco come ho imparato ad apprezzare la scelta al college. Nel client-server, il server gestisce le risorse e , in particolare , tutte le risorse che devono essere condivise . Quindi, il server X è il processo che serve, alle app client , alla tastiera, al mouse e al framebuffer (o, comunque tu scriva sullo schermo sul tuo sistema).

Anche se non proprio corretto, il gestore delle finestre viene spesso spiegato in questo modo: è semplicemente quella cosa che mette maniglie e altre decorazioni sulla cornice di un'app e finestre, finestre di dialogo, ecc.

I modelli client-server sono un design popolare per tutti i tipi di applicazioni, anche quando c'è un solo server e un solo client. Consentono un'interfaccia pulita e ben definita tra i domini di responsabilità.

Mentre ci sono molti modi in cui un server e un client possono comunicare, la scelta fatta da X(indipendentemente dai vantaggi menzionati da altri) non è superflua: è possibile connettersi a un Xserver su un altro computer e aprire finestre sul desktop (o su un altro collaboratore desktop). Questo era molto comune ai tempi in cui X era stato sviluppato, quando molte università e aziende avrebbero avuto un server Unix e molti "terminali X" che ne parlavano. Utilizzando un protocollo di comunicazione pronto per Internet, X può essere utilizzato senza problemi all'interno o tra gli host.

X è stato il primo ambiente con interfaccia grafica in grado di visualizzare in modo trasparente finestre da un altro computer, in linea con la storia di UNIX come ambiente multiutente anziché come sistema operativo per un singolo utente su un singolo computer. Molte funzionalità di UNIX sembrano eccessive se sei l'unica persona che interagisce mai (fisicamente o in remoto) con il tuo computer.

Credo che l'x-server sia stato progettato come un'architettura client-server perché inizialmente le risorse di elaborazione erano scarse e i mainframe hanno svolto la maggior parte del lavoro pesante. I terminali X erano solo thin client che si connettevano agli x-server e mostravano tutto ciò che doveva essere mostrato all'utente.

Ha molti vantaggi (anche se il protocollo di comunicazione per X è molto pesante al giorno d'oggi), in particolare è possibile visualizzare lo stesso display su più client, condividere uno schermo con più utenti è facile in X.