Noctiluca - Parece que o futuro do software de controle remoto não era o WebRTC, mas sim o QUIC

Olá, sou unstabler. Estou escrevendo pela primeira vez.
Não costumo escrever com frequência, então o texto pode estar meio desorganizado e longo, mas peço a compreensão de vocês!

Passei a ficar obcecado com o macOS justamente porque não gosto do macOS

Desde 2011, venho usando principalmente desktops Linux. Passei por Ubuntu, Debian e Fedora, e continuei usando Arch Linux + KDE Plasma como meu sistema principal. Por vários motivos, em 2021 acabei abrindo uma empresa que funciona meio como uma prestadora de serviços de TI, e fui aceitando todo tipo de trabalho que parecesse interessante, seja C++ embarcado, aplicativo mobile ou um site simples.

Nesse processo, o volume de trabalho com apps para iOS foi aumentando cada vez mais. Só que eu não queria muito usar Mac. No começo, tentei até mudar atalhos com o Karabiner e coisas do tipo, e também acessava a máquina pelo Google Remote Desktop para trabalhar, mas era lento demais, e no Xcode o teclado e o mouse às vezes se comportavam de forma estranha, o que me gerava muito estresse.

Pensando bem, RDP! Tinha o xrdp!

De repente me lembrei do RDP. Embora o RDP seja um protocolo desenvolvido para Microsoft Windows, existia uma implementação open source chamada xrdp. Só que o xrdp parte do pressuposto de uso com X11 por padrão, e no macOS era possível usar a combinação de compartilhamento de tela nativo + backend VNC, mas se a resolução da tela não fosse ajustada em 1:1, ficava praticamente impossível de usar.

Então acabei criando um plugin de backend para xrdp chamado '麗 -ulalaca-', baseado no backend VNC do xrdp e no ScreenCaptureKit, mas ele não chegou a um nível realmente utilizável no dia a dia.

• Suporte a GFX (H.264) / RFX que desapareceu nas versões mais recentes do Windows (mstsc.exe):
  Quando comecei o desenvolvimento, o suporte aos codecs GFX / RemoteFX já estava começando a desaparecer. O FreeRDP, cliente para Linux, ainda mantém esse suporte, mas nas versões atuais do Windows parece ter restado apenas compressão baseada em RLE.
• Dificuldade extrema de desenvolvimento / depuração: fora a parte de exibição da tela, desenvolver era difícil demais, e depurar também era muito complicado. No começo eu estava bem empolgado e queria implementar saída de áudio, sincronização de clipboard e outras coisas, mas como eu já lidava com ADHD, perdi o interesse rapidamente.

Vamos refazer isso com WebRTC! Mas...

Depois de deixar o ulalaca parado por cerca de meio ano, enquanto pensava no Noctiluca me veio a ideia de “vamos fazer direito de novo com WebRTC!”. Mas implementar WebRTC também não foi nada fácil.

• Dificuldade de customização: para usar os dados da tela como fonte de vídeo, era necessário baixar e modificar o código-fonte do Google Chromium. Quando a codificação por hardware deixou de funcionar depois de eu alterar parâmetros de codec, para descobrir o motivo eu precisava vasculhar o código-fonte, adicionar logs e recompilar tudo toda vez.
• Impossibilidade de fixar portas: também era necessário um servidor de signaling, além de TURN/STUN, e acima de tudo não era possível fixar a porta de saída nem reutilizar portas. Foi sofrido demais.
• A maldição do SCTP: o WebRTC DataChannel usa SCTP internamente. Existe um problema em que, quando o tamanho do payload de uma mensagem passa do MTU, começam a surgir travamentos nos streams de vídeo e áudio.

No fim das contas, depois de tantas voltas, QUIC

Cansado da complexidade do WebRTC, acabei deixando o Noctiluca de lado por quase mais meio ano. Um dia, voltando para casa depois de ficar pensando à toa num café, me veio à cabeça o QUIC, que serve de base para o HTTP/3. Como o Network.framework no macOS / iOS também já fornecia uma implementação de QUIC, consegui montar rapidamente um protótipo com base no código que já tinha, e nesse nível de protótipo os problemas abaixo foram resolvidos imediatamente.

• Resolução do Head-of-Line Blocking (HOL): o maior problema das soluções baseadas em TCP, ou do WebRTC DataChannel que usa SCTP, é que quando um único pacote se perde, todos os dados seguintes param. Já no QUIC, os streams são independentes. Mesmo que um pacote de áudio falhe, a entrada do mouse e os frames de vídeo continuam chegando.

• Uma única porta UDP e Connection Migration: não foi preciso montar uma estrutura complicada com servidor de signaling, STUN/TURN e tudo mais como no WebRTC. Bastava abrir uma única porta UDP e pronto. Mesmo trocando de ponto de acesso Wi-Fi, a conexão continuava ativa graças ao Connection Migration.

Conclusão: estou recrutando beta testers!

Estou recrutando beta testers para um software de controle remoto chamado 'Noctiluca', que nasceu dessa história toda.

• Usa um protocolo próprio chamado 'Sirius', baseado em QUIC.

  • Pretendo abrir o código assim que a especificação e outros detalhes forem definidos!

• Suporta H.264 / H.265 (HEVC).

  • Também suporta codecs de imagem tradicionais baseados em blocos para ambientes de VM (MJPG, RLE, WebP).

• Suporta transmissão de conteúdo HDR. (experimental)

• É possível negociar os requisitos de codec entre cliente e servidor.

• Suporta autenticação com PAM (usuário-senha), somente senha e chave SSH.

• As funcionalidades podem ser expandidas por plugins. No futuro, pretendo implementar coisas como fail2ban e oferecer isso como recurso adicional.

  • Também é possível escrever plugins diretamente para expandir o mecanismo de autenticação.

• No momento, o cliente existe apenas para iOS / macOS.

  • Pretendo desenvolver clientes para Linux / Windows baseados em Qt / C++!

Até o dia em que eu conseguir desenvolver apps iOS com meu laptop Linux!
Hoje também continuo nessa jornada para voltar ao meu laptop Linux.

Obrigado.

(+ Na verdade, eu não sabia se podia colocar diretamente aqui um link do Google Drive, então por enquanto estou deixando como link o post no X que publiquei quando apresentei isso antes..!)

• Link do Google Drive da primeira versão de teste: https://drive.google.com/drive/folders/1r4m7lGZ-f988dp_piLAEwlJRLPODPNQq?usp=drive_link

(++ É meio que um subproduto feito com vibe coding enquanto eu desenvolvia o Noctiluca(?), mas peço a atenção de vocês para este também..!)

• swift-msquic: módulo wrapper criado para facilitar o uso do MsQuic em Swift no iOS / macOS!
• Xuanxue: módulo que permite fazer assinatura / verificação de assinatura usando chave SSH em Swift! Eu estava com tanta preguiça que queria o caminho mais fácil para tudo, então dei esse nome por isso!

[channprj]

Muito legal!! 👍🏻

[jjpark78]

Uso o Parsec

[jjpark78]

Tirando a limitação de precisar ter o mesmo tamanho de monitor, parece ser a melhor ferramenta de acesso remoto.
Para mim, o iPad não ser compatível é algo totalmente irrelevante.

[lux1024]

Eu também uso o parsec, e acho que fiquei realmente chocado quando descobri que ele de fato não funciona no mobile. Quem diria... haha

Na verdade, para desenvolvimento em iOS/macOS, parece que o melhor mesmo é simplesmente usar um Mac mini ou MacBook conectado por KVM, mas acaba sendo meio trabalhoso.

[unstabler]

Na verdade, se eu puder continuar desenvolvendo o Noctiluca, gostaria de criar um recurso parecido com o conceito de 'RemoteApp' do Microsoft RDP. E também redirecionamento de USB!

Se eu conectar um iPhone no meu ThinkPad e ele for reconhecido da mesma forma no Mac que está em outro cômodo, e eu puder usar só a janela do Xcode em vez da 'tela cheia' do Mac, acho que ficaria muito feliz.

[unstabler]

Então, também estamos projetando/implementando recursos relacionados..!

Ainda não está nada organizado, então a única coisa que posso mostrar por enquanto é isto T_T

https://gist.github.com/unstabler/25679baab3a65a3c19f747c38f30c1b3

[moderator]

Substituí o link original por um link do Drive e inseri o link do post no X no corpo do texto.

[bus710]

Eu estava pensando em como acessar o Mac, mas só tinha aquela ideia vaga de que talvez desse para dar um jeito com jetkvm e tailscale.
Se for pelo método do texto, então deve dar até sem KVM.