Processamento Remoto de Programas e Games

Entenda como é a tecnologia por trás do streaming de games via internet em serviços como o STADIA da Google, Microsoft xCloud ou PlayStation® Now, com este sistema caseiro de processamento remoto utilizando SSH!


| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. 
Mais detalhes clicando aqui.


Introdução

O processamento remoto via tunelamento SSH é algo relativamente antigo, mas que perdura até os dias de hoje como uma ferramenta nativa das distros Linux.

Inicialmente seu objetivo era multiplicar o multi-processamento de uma máquina ao utilizar o poder de outras na mesma rede como se fossem 1 só. Ao nome disso, industrialmente chamamos de Clustering, quando vários processadores via Ethernet computam dados como se fossem um só.

Já o processamento remoto é algo mais simples: Você estará abrindo um programa em uma máquina porém vendo a interface dela na atual que está fazendo a conexão. Isso se deve ao fato do X.Org, o gerenciador gráfico padrão de 99.9% das distros Linux, permitir enviar a interface gráfica por dentro do túnel SSH.

E hoje trago a vocês uma pequena dica para quem quer se divertir “criando” seu próprio serviço de streaming de aplicativos e/ou games graças ao processamento remoto, fazendo uso daquele gabinete que está encostado sem funcionar a um tempo, de uma forma mais simples do que se fosse com um cluster convencional.

Processamento Remoto

Você vai precisar de…

  • Interesse é essencial!
  • Sistema Linux de sua preferência em todos os computadores envolvidos.
  • Cabos de Ethernet decentes. Cabos CAT 5e ou 6 são ideais.
  • Um switch ethernet /1000.
    Se você possuir uma rede doméstica /100, também poderá fazer o procedimento porém notará lentidão.
  • Hardware que suporte a conectividade /1000.
  • Que os sistemas Linux das máquinas estejam executando o XOrg ou que tenha o pacote SSH instalado e configurado.

Os computadores que você pretende utilizar no processamento remoto, ao lado do seu, devem estar ligados á mesma rede. Apenas plugue os cabos de rede – evite Wifi, tem baixo desempenho – de todas as máquinas, inclusive a sua, no mesmo switch.

Configurando

  • Ligue as máquinas.
  • Certifique-se de que o pacote ssh está instalado em todas as máquinas.
  • Verifique o IP local e o usuario das 2 máquinas.
  • No terminal utilize o comando “ping IP” para garantir a conexão com as demais máquinas.
  • Para se conectar, utilize o comando:
    $ ssh -X usuario@IP
  • Se bem sucedido, em seu terminal você verá a saída do terminal da máquina servidora que pretende utilizar.

O parâmetro -X é importante para habilitar a transmissão do Servidor X pelo SSH.
Uma vez conectado, basta executar um programa de sua preferencia.
Exemplo?

$ ssh -X nathandrake@192.168.0.22
$ firefox

Pronto, o sistema vai carregar o Firefox no outro computador e vai me exibir a saída do comando no meu PC.
Assim, o Firefox estará aberto e sua memória RAM estará tranquila.
Videos pelo Youtube ficarão lentos e sites mais pesados como o Facebook podem ficar com alguns delays mas o Messenger e Telegram por exemplo, abre tranquilamente.

  • Canto superior esquerdo, terminal que fez a conexão SSH -X.
  • Lado direito, Firefox aberto remotamente.
  • Canto inferior esquerdo, terminal local informando memória consumida: Apenas ~400Mb.

Se você abrir o gerenciador de processos, verá que o Firefox não estará listado!

Nos meus testes fui bem sucedido inclusive em sistemas com arquitetura diferente. No vídeo a seguir, executei o Google Sketchup 8 em outro computador (arquitetura x86_64) porém utilizando acesso remoto via SSH num Raspberry Pi 3 (ARM) com tela touch. Note o cabeçalho da janela que diz: “em msi-cubi”, o computador remoto. Eis o resultado:

Esta foi uma pequena demonstração do meu Notebook Pi, o qual abordei nesta publicação com mais detalhes e imagens.

Games

Fiz testes com games via SSH, transmitidos da mesma maneira.

Neste outro vídeo onde estreio meu talento como Youtuber, #sóquenão, demonstro na prática como foi executar Doom 3 Anthology do Grupo Bonobo via SSH. Games compilados nativos para Linux e mais leves executam bem!

Transcrevendo o que fiz no vídeo:

  1. Possuo um notebook com especificações gamers, como GTX 1050 e Core i5.
  2. Os testes foram feitos num computador cliente mais simples, um Intel NUC com i5 de 5a geração @ 1.4Ghz (bem fraco!)
  3. Ambas as máquinas possuem placa de rede gigabit /1000
  4. Ambas estavam conectadas num Switch /1000
  5. Abri o gerenciador de processos e o visualizador de processos do Linux, mostrando o uso de CPU e da placa de rede.
  6. Na máquina cliente fiz a conexão SSH e executei o Doom 3 Anthology normalmente via ./Doom3.x64, binário nativo de Linux.
  7. Logo que o jogo iniciou o som saiu na máquina original. A migração do audio para a máquina cliente ainda não sei informar como é.
  8. O jogo ficou plenamente jogável na faixa dos 60 FPS processado na máquina servidora (notebook) e transmitido para o Intel NUC, a máquina cliente.

Evite games do Wine/Proton/Lutris.
Fiz testes inclusive com o Portal, da Valve, nativo para Linux na Steam, porém a lentidão deixou o jogo injogável. Quanto mais pesados os gráficos, mais exigir da placa de vídeo, mais lento ficará. Em seus testes, procure testar games mais simples!

Caso tenha se interessado no jogo, em breve ele estará disponível na loja oficial do Grupo Bonobo com binários nativos para Linux e suporte a Ray Tracing.

Streaming

Obviamente o serviço de streaming das grandes empresas não é tão simples. Não apenas usam algoritmos de compressão de vídeo diferentes para maximizar as transmissões e otimizar os tempos de resposta, os servidores possuem recursos próprios e hardware dedicado para tal. Curiosamente o STADIA da Google foi demonstrado executando Assassins Creed Odyssey sob Linux no lado servidor; Se era um sistema nativo (com o game compilado) ou uma máquina virtualizada do Windows, só o tempo (e os técnicos) dirão.

Conclusão

Este não é um projeto Cluster, mas uma maneira paliativa de utilizar processamento extra em seu dia a dia seja para experimentos, seja para jogar, seja para utilização em sistemas de alta prioridade.

Um Cluster de verdade possui a função de rodar 1 programa em todas as máquinas com processamento dividido em todos os nucleos das CPU’s; Ou seja, se a soma dos núcleos de seus, seilá 3 ou 4 computadores for 12, então teremos 15! Mas para isso o programa deve ser compilado para suportar todas aquelas CPUs – E não, nativamente 99.9% dos programas desenvolvidos para usuários Linux de desktop não são projetados para fazer uso de tantos processadores de forma eficiente. Nem games.

Por isso eu trouxe esse tutorial de processamento remoto, ele será mais prático e melhor aproveitado pelos usuários finais domésticos, estudantes e entusiastas!

#UrbanCompassPony

Deixe um comentário