Por que o X Window System usa um servidor?

Question

Eu nunca entendi realmente porque um sistema de janelas deve ter um servidor. Por que os ambientes de área de trabalho, gerenciadores de exibição e gerenciadores de janelas precisam do servidor xorg? É apenas para ter uma camada de abstração no topo da placa gráfica? Por que os sistemas de janela empregam um modelo cliente-servidor? A comunicação entre processos através de pipes nomeados não seria mais simples?

    

Answer 1

Acho que você já percebeu que é necessário algum tipo de "servidor". Cada cliente (ambiente de área de trabalho, gerenciador de janelas ou programa em janelas) precisa compartilhar a exibição com todos os outros, e eles precisam exibir as coisas sem conhecer os detalhes do hardware ou saber quem mais está usando a exibição. Assim, o servidor X11 fornece a camada de abstração e compartilhamento que você mencionou, fornecendo uma interface IPC.

O X11 provavelmente poderia ser executado em canais nomeados, mas há duas grandes coisas que os pipes nomeados não podem fazer.

• Os pipes nomeados só se comunicam em uma direção.
• Se dois processos começarem a colocar dados no final de "envio" de um canal nomeado, os dados serão misturados.

Na verdade, a maioria dos clientes X conversa com o servidor usando um canal nomeado "novo e aprimorado" chamado soquete do domínio UNIX. É muito parecido com um pipe nomeado, exceto que permite que os processos falem em ambas as direções e controla quem disse o quê. Esses são os mesmos tipos de coisas que a rede precisa fazer, e assim os soquetes de domínio UNIX usam a mesma interface de programação que os soquetes TCP / IP que fornecem comunicações de rede.

Mas a partir daí, é muito fácil dizer "E se eu executasse o servidor em um host diferente do cliente?" Basta usar um soquete TCP em vez do soquete UNIX e voila: um protocolo de desktop remoto que antecede o Windows RDP por décadas. Eu posso ssh para quatro hosts remotos diferentes e executar synaptic (gerenciador de pacotes gráfico) em cada um deles, e todas as quatro janelas aparecem no display do meu computador local.

    

Answer 2

Um sistema de janelas não precisa ter um servidor, mas você pode decidir implementar o sistema de janelas com base em um modelo cliente-servidor. Isso tem várias vantagens, pois você separa claramente as atividades no cliente e no servidor, elas não precisam ser executadas na mesma máquina e é mais fácil atender a vários clientes. Isso ainda é muito útil (por exemplo, quando você ssh em outra máquina), mas você tem que perceber que no momento em que X foi desenvolvido, isso era visto como uma necessidade: sua máquina local pode não ser poderosa o suficiente para executar o cliente .

Os pipes nomeados não lhe dariam a vantagem automática de poder passar pela rede como uma implementação TCP faria. Mas os tubos nomeados eram, e. não disponível no DOS, com DosExtender executando Desqview / X (1992), e AFAIK também não no VMS. Para essas implementações, uma comunicação específica do Unix seria um problema.

O TCP não é específico do Unix e é possível ter um cliente executado no VAX / VMS (desenvolvimento X iniciado em 1984) e servir a saída para sua estação de trabalho gráfica local baseada no UNIX. Do "X Window System: A referência completa para Xlib, protocolo X, ICCCM, XLFD "¹:

During the fall of 1986, Digital decided to base its entire desktop workstation strategy for ULTRIX, VMS, and MS-DOS on X. Although this was gratifying to us, it also meant we had even more people to talk to. This resulted in some delay, but, in the end, it also resulted in a better design. Ralph Swick of Digital joined Project Athena during this period and played a vital role thoughout version 11’s development. The last ver- sion 10 release was made available in December 1986.

Do "Manual de referência do protocolo X" ²:

Division of responsibilities

In the process of designing the X protocol, much thought went into the division of capability between the server and the client, sind this determines what information has to be passed back and forth through requests, replies and events. An excellent source of information about the rationale behind certain choices made in designing the protocol is the article The X Window System, by Robert W. Scheifler and Jim Gettys, published in the Association of Computing Machinery journal Transaction on Graphics, Vol 5, No. 2, April 1986 The decisions ultimately reached were based on portability of client programs, ease of client programming, and performance.

First, the server is designed, as much as possible, to hide differences in the underlying hardware from client applications. ...

Eu lembro do artigo no TOG ser uma leitura interessante. Isso certamente despertou meu interesse por X e (isso foi antes da WorldWideWeb) a dificuldade em colocar as mãos em mais informações até a O'Reilly começar a publicar seus livros da série X.

¹ _{X Versão 11, Release 4, página 2-X, PDF disponível online aqui}
² _{É a partir da página 9 na 2ª edição, publicada pela O'Reilly, que eu comprei em 1990. Há edições mais recentes, mas eu nunca me preocupei em comprá-las e elas são AFAIK disponíveis apenas no papel também. Eu não acho que eles mudaram a lógica da divisão de responsabilidades.}

    

Answer 3

Um sistema de janelas significa que vários programas independentes compartilham um recurso comum, a tela e os dispositivos de entrada. Recursos compartilhados só podem ser implementados com segurança de duas maneiras:

• O recurso pode ser controlado pelo kernel e os aplicativos fazem chamadas do kernel para acessá-lo.
• O recurso pode ser controlado por um processo dedicado (servidor) e os aplicativos contatam o servidor para acessá-lo.

Obviamente, o acesso ao hardware de exibição atual é controlado pelo kernel, mas isso não é suficiente para um sistema de janelas: deve haver uma maneira de um processo ser atribuído a uma determinada parte do display (a janela) onde pode estar razoavelmente seguro de que nenhum outro processo irá interferir, e deve haver um certo nível de proteção de qual aplicativo pode acessar qual parte do recurso em que momento.

Agora, tudo poderia ter entrado no kernel, que é o AFAIK, o que o Windows faz. Isto tem a vantagem de ser mais rápido (geralmente chamar o kernel é muito mais rápido do que entrar em contato com outro processo), mas tem a desvantagem de possivelmente abrir brechas de segurança (qualquer exploit do sistema é um exploit no kernel) e ao mesmo tempo time restringe a portabilidade (um sistema implementado no kernel é strongmente acoplado ao kernel; você não será capaz de portá-lo facilmente para outro sistema operacional, e completamente incapaz de fazer se você não tiver acesso ao código do kernel).

Se você não quiser implementá-lo no kernel, a única outra maneira de implementá-lo é como um processo dedicado, isto é, um servidor. Observe que um servidor que é contatado por meio de pipes nomeados ainda é um servidor. Além disso, quando executados na mesma máquina, grande parte da comunicação entre o servidor X e os clientes acontece por meio da memória compartilhada atualmente; isso ainda não muda o fato de que o servidor de exibição é um servidor.

Agora, por que o servidor é contatado usando soquetes e não está usando pipes nomeados? Bem, se você fizer isso usando soquetes, você só precisa ter um soquete para todo o servidor, o que pode fazer toda a comunicação. Se você se comunicar com pipes, precisará de dois canais por cliente. Além do fato de que gerenciar todos esses canais seria bastante complicado, você também pode atingir alguns limites do sistema operacional quanto ao número de canais abertos se muitos programas tentarem conversar com o servidor ao mesmo tempo.

E, claro, outra vantagem de sockets over pipes é que com sockets você pode ter conexões entre máquinas, o que era especialmente importante em um momento em que o computador real era compartilhado por muitas pessoas sentadas em terminais dedicados, portanto os programas no computador tinha que se comunicar com os diferentes terminais, mas ainda é muito útil até hoje em ambientes de rede.

    

Answer 4

X foi originalmente desenvolvido e mantido por M.I.T. E, foi com uma licença de código aberto M.I.T, não isso, isso realmente importa.

Enquanto visto como não-convencional, considere por um momento; como você explicaria a opção de usar um paradigma cliente-servidor em um software? E talvez eu deva dizer para um C.EO ...

Veja como aprendi a apreciar a escolha na faculdade. No cliente-servidor, o servidor gerencia os recursos e especialmente , quaisquer recursos que devem ser compartilhados . Então, o servidor X é o processo que serve para os aplicativos cliente , o teclado, mouse e framebuffer (ou, no entanto, você escreve na tela do seu sistema).

Embora não seja realmente correto, o gerenciador de janelas é frequentemente explicado da seguinte forma: é simples, aquela coisa, que coloca alças e outras decorações no quadro de um aplicativo, além de janelas, diálogos, etc.

    

Answer 5

Os modelos cliente-servidor são um design popular para todos os tipos de aplicativos, mesmo quando há apenas um servidor e apenas um cliente. Eles permitem uma interface limpa e bem definida entre domínios de responsabilidade.

Embora haja muitas maneiras de comunicação entre um servidor e um cliente, a escolha feita por X (independentemente das vantagens mencionadas por outras pessoas) não é supérflua: pode se conectar a um X servidor em uma máquina diferente e abra as janelas na sua área de trabalho (ou em outra área de trabalho colaboradora). Isso costumava ser muito comum nos dias em que o X foi desenvolvido, quando muitas universidades e empresas tinham um servidor Unix e muitos "terminais X" que conversavam com ele. Ao usar um protocolo de comunicações pronto para uso na Internet, o X pode ser usado sem interrupções dentro ou entre hosts.

O X foi o primeiro ambiente de GUI que podia transparentemente exibir janelas de outra máquina, consistente com o histórico do UNIX como um ambiente multiusuário, em vez de um SO para um único usuário em um único computador. Muitos recursos do UNIX parecem um exagero se você for a única pessoa que consegue interagir (física ou remotamente) com seu computador.

    

Answer 6

Acredito que o x-server foi projetado como uma arquitetura cliente-servidor, porque inicialmente os recursos de computação eram escassos e os mainframes faziam a maior parte do trabalho pesado. Os terminais X eram apenas thin clients que se conectavam a x-servers e exibiam o que precisava ser exibido para o usuário.

Tem muitos benefícios (embora o protocolo de comunicação para o X seja muito pesado hoje em dia), notavelmente você pode exibir a mesma tela em vários clientes, é fácil compartilhar uma tela com vários usuários no X.