Eu realmente nunca entendi por que um sistema de janelas deve ter um servidor. Por que ambientes de desktop, gerenciadores de exibição e gerenciadores de janelas precisam do xorg-server? É apenas para ter uma camada de abstração em cima da placa gráfica? Por que os sistemas de janelas empregam um modelo cliente-servidor? A comunicação entre processos por meio de pipes nomeados não seria mais simples?
Responder1
Acho que você já percebeu que é necessário algum tipo de "servidor". Cada cliente (ambiente de desktop, gerenciador de janelas ou programa em janela) precisa compartilhar a tela com todos os outros e precisa ser capaz de exibir coisas sem conhecer os detalhes do hardware ou saber quem mais está usando a tela. Portanto, 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 pipes nomeados, mas há duas grandes coisas que os pipes nomeados não podem fazer.
- Os pipes nomeados se comunicam apenas em uma direção.
- Se dois processos começarem a colocar dados na extremidade de "envio" de um canal nomeado, os dados serão misturados.
Na verdade, a maioria dos clientes X se comunica com o servidor usando um canal nomeado "novo e melhorado" chamado soquete de domínio UNIX. É muito parecido com um pipe nomeado, exceto que permite que os processos se comuniquem nas duas direções e monitora quem disse o quê. Esses são os mesmos tipos de coisas que a rede precisa fazer e, portanto, 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í, é realmente 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 pronto: um protocolo de área de trabalho remota que antecede o Windows RDP em décadas. Posso sshacessar quatro hosts remotos diferentes e executar synaptic(gerenciador gráfico de pacotes) em cada um deles, e todas as quatro janelas aparecem na tela do meu computador local.
Responder2
Um sistema de janelas não precisa ter um servidor, mas você pode decidir implementar um sistema de janelas baseado em um modelo cliente-servidor. Fazer isso tem diversas 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 vários clientes. Atualmente, isso ainda é muito útil (por exemplo, quando você sshusa outra máquina), mas você precisa perceber que, na época em que o X foi desenvolvido, isso era visto como uma necessidade: sua máquina local pode não ser poderosa o suficiente para executar o cliente.
Pipes nomeados não dariam a vantagem automática de poder rodar pela rede como faria uma implementação TCP. Mas os pipes nomeados, por exemplo, não estavam disponíveis no DOS, com o DosExtender rodando Desqview/X (1992), e o AFAIK também não estava 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 rodando em VAX/VMS (o desenvolvimento do X começou em 1984) e servindo a saída para sua estação de trabalho gráfica local baseada em UNIX. Do "Sistema X Window: A referência completa ao Xlib, protocolo X, ICCCM, XLFD"¹:
Durante o outono de 1986, a Digital decidiu basear toda a sua estratégia de estações de trabalho desktop para ULTRIX, VMS e MS-DOS no X. Embora isso fosse gratificante para nós, também significava que tínhamos ainda mais pessoas com quem conversar. Isto resultou em algum atraso, mas, no final, também resultou num design melhor. Ralph Swick da Digital juntou-se ao Project Athena durante este período e desempenhou um papel vital durante o desenvolvimento da versão 11. A última versão 10 foi disponibilizada em dezembro de 1986.
Do "Manual de Referência do Protocolo X"²:
Divisão de responsabilidades
No processo de projeto do protocolo X, muita reflexão foi dedicada à divisão de capacidade entre o servidor e o cliente, e isso determina quais informações devem ser transmitidas através de solicitações, respostas e eventos. Uma excelente fonte de informações sobre a lógica por trás de certas escolhas feitas no projeto do protocolo é o artigo The X Window System, de Robert W. Scheifler e Jim Gettys, publicado na revista Association of Computing Machinery Transaction on Graphics, Vol 5, No. 2 de abril de 1986 As decisões finalmente tomadas basearam-se na portabilidade dos programas clientes, na facilidade de programação do cliente e no desempenho.
Primeiro, o servidor é projetado, tanto quanto possível, para ocultar diferenças no hardware subjacente dos aplicativos clientes. ...
Lembro-me de que o artigo no TOG foi uma leitura interessante. Certamente despertou meu interesse por X e (isso foi antes da WorldWideWeb) a dificuldade que tivemos em obter mais informações até a O'Reilly começar a publicar sua série de livros X.
¹ X Versão 11, Release 4, página 2-X, PDF disponível onlineaqui
² Isto é da página 9 da 2ª edição, publicada pela O'Reilly, que comprei em 1990. Existem edições mais recentes, mas nunca me preocupei em comprá-las e estão AFAIK disponíveis apenas em papel também. Não creio que tenham mudado a lógica da divisão de responsabilidades.
Responder3
Um sistema de janelas significa que vários programas independentes compartilham um recurso comum, a tela e os dispositivos de entrada. Os recursos partilhados só podem ser implementados com segurança de duas maneiras:
- O recurso pode ser controlado pelo kernel e os aplicativos fazem chamadas ao kernel para acessá-lo.
- O recurso pode ser controlado por um processo dedicado (servidor), e as aplicações entram em contato com o servidor para acessá-lo.
É claro que o acesso ao hardware de exibição real é controlado pelo kernel, mas isso não é suficiente para um sistema de janelas: deve haver uma maneira de um processo receber um determinadopapelda tela (a janela), onde se pode ter certeza razoável 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 e em que momento.
Agora a coisa toda poderia ter ido para o kernel, que é 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), porém tem a desvantagem de possivelmente abrir brechas de segurança (qualquer exploração do sistema é uma exploração no nível do kernel), e ao mesmo tempo o tempo restringe a portabilidade (um sistema implementado no kernel está fortemente acoplado ao kernel; você não será capaz de portá-lo facilmente para outro sistema operacional e será completamente incapaz de fazê-lo se não tiver acesso ao código do kernel).
Se você não quiser implementá-lo no kernel, a única outra forma de implementá-lo é como um processo dedicado, ou seja, um servidor. Observe que um servidor contatado por meio de pipes nomeados ainda é um servidor. Além disso, quando executado na mesma máquina, grande parte da comunicação entre o servidor X e os clientes acontece atualmente através de memória compartilhada; 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 usando pipes nomeados? Bem, se você fizer isso usando soquetes, você só precisa ter um soquete para todo o servidor, que pode fazer toda a comunicação. Se você se comunicar com pipes, precisará de dois pipes por cliente. Além do fato de que gerenciar todos esses pipes seria bastante complicado, você também poderá atingir alguns limites do sistema operacional no número de pipes abertos se um número suficiente de programas tentarem se comunicar com o servidor ao mesmo tempo.
E, claro, outra vantagem dos soquetes sobre os tubos é que com os soquetes você pode ter conexões entre máquinas, o que era especialmente importante numa época em que o computador real era compartilhado por muitas pessoas sentadas em terminais dedicados, de modo que os programas no computador tinham que se comunicar. aos diferentes terminais, mas ainda hoje é muito útil em ambientes de rede.
Responder4
Os modelos cliente-servidor são um design popular para todos os tipos de aplicações, mesmo quando há apenas um servidor e apenas um cliente. Eles permitem uma interface limpa e bem definida entre os domínios de responsabilidade.
Embora existam muitas maneiras de um servidor e um cliente se comunicarem, a escolha feita por X(independentemente das vantagens mencionadas por outros) não é supérflua: vocêpodeconecte-se a um Xservidor em uma máquina diferente e abra janelas em sua área de trabalho (ou em outra área de trabalho cooperante). Isso costumava ser muito comum na época 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ção pronto para Internet, o X pode ser usado perfeitamente dentro ou entre hosts.
X foi o primeiro ambiente GUI que podia exibir janelas de outra máquina de forma transparente, consistente com a história do UNIX como um ambiente multiusuário, em vez de um sistema operacional 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.