Transferência de arquivos CDC

• CDC File Transfer é uma ferramenta de código aberto desenvolvida pelo Google que oferece sincronização e streaming de arquivos entre Windows e Linux
• Usa a tecnologia Content Defined Chunking (CDC), que transmite apenas as partes alteradas do arquivo, alcançando velocidade até 30 vezes maior que o rsync tradicional
• Fornece duas ferramentas principais, cdc_rsync e cdc_stream, responsáveis respectivamente por sincronização de arquivos e streaming em tempo real
• Foi projetada para que desenvolvedores baseados em Windows possam implantar e testar arquivos com eficiência em ambientes Linux, sendo excelente para desenvolvimento remoto e ambientes de desenvolvimento de jogos
• Oferece suporte a autenticação baseada em ssh e sftp, tem uso intuitivo e disponibiliza binários para várias plataformas

---

Visão geral e importância do projeto

• CDC File Transfer é um conjunto de ferramentas de transferência de arquivos de código aberto lançado pelo Google, que processa de forma rápida e eficiente a sincronização e o streaming de arquivos entre Windows e Linux ou entre máquinas Windows
• O projeto foi criado para o ambiente de desenvolvimento de jogos do Stadia e surgiu para resolver as limitações de ferramentas como scp e rsync (transferência lenta, cópia de arquivos inteiros, ausência de modo delta)
• A tecnologia central é o algoritmo FastCDC, um tipo de Content Defined Chunking, otimizado para grandes sincronizações repetidas por transmitir apenas os dados realmente alterados quando um arquivo muda
• Mesmo sendo open source, oferece desempenho em nível comercial (por exemplo, velocidade de sincronização de 1500 MB/s e streaming de 2 a 5 vezes mais rápido que sshfs), com eficiência claramente superior à de serviços concorrentes em ambientes de desenvolvimento remoto e em nuvem

Explicação das principais ferramentas

cdc_rsync

• É uma ferramenta para sincronizar arquivos do Windows para o Linux e supera as limitações do rsync tradicional no Linux
• Arquivos com horário e tamanho correspondentes são rapidamente ignorados, e apenas os arquivos alterados são transmitidos com eficiência
• Usando FastCDC, detecta e transmite apenas a posição dos dados modificados, oferecendo tráfego mínimo e transferência rápida
• Em testes de sincronização, apresentou desempenho cerca de 3 vezes superior ao rsync executado no Cygwin e muito mais rápido que o rsync padrão no Linux
• Oferece suporte a compressão de alta velocidade e uma estrutura de algoritmo simples, porém eficiente, que verifica os arquivos até o nível de byte

cdc_stream

• Permite acessar pastas e arquivos do Windows no Linux por streaming em tempo real, como se fossem arquivos locais
• Tem estrutura semelhante ao sshfs, mas com velocidade de leitura de arquivos e desempenho de cache otimizados
• Por meio de detecção de mudanças e streaming diferencial, retransmite apenas os dados alterados e também processa metadados rapidamente
• Os diretórios Linux são disponibilizados como readonly, e arquivos alterados no Windows são refletidos no Linux quase imediatamente (em no máximo alguns segundos)
• Em ambientes de desenvolvimento que exigem acesso a arquivos grandes, como dados de jogos, mostrou na prática ganho de desempenho de 2 a 5 vezes em relação ao sshfs

Plataformas compatíveis

• cdc_rsync: suporte principal entre Windows x86_64 ↔ Ubuntu 22.04 x86_64, com suporte gradual a sincronização remota e sincronização local
• cdc_stream: suporte a streaming de Windows x86_64 para Ubuntu 22.04 x86_64; a direção inversa e outras plataformas não são suportadas

Métodos de autenticação/configuração

• Método de autenticação sem senha por meio de ssh.exe e sftp.exe (recomenda-se autenticação baseada em chave)
• No Windows, é possível especificar caminhos detalhados dos comandos pela linha de comando ou por variáveis de ambiente
• É possível usar opções adicionais de comandos SSH e arquivos de configuração por usuário (%USERPROFILE%\\.ssh\\config)
• Usuários internos do Google contam com variáveis de ambiente específicas para autenticação baseada em chave de segurança

Exemplos de uso

Exemplos de uso do cdc_rsync

• Sincronização de arquivo: cdc_rsync C:\path\to\file.txt [e-mail]:~
• Suporte a curingas e sincronização recursiva de diretórios inteiros: cdc_rsync C:\path\to\assets\* [e-mail]:~/assets -r
• É possível verificar o status da sincronização em tempo real (opção -v) e também sincronizar entre arquivos locais

Exemplos de uso do cdc_stream

• Iniciar streaming de diretório: cdc_stream start C:\path\to\assets [e-mail]:~/assets
• Encerrar sessão de streaming: cdc_stream stop [e-mail]:~/assets
• É possível gerenciar várias sessões com curingas

Solução de problemas e logs

• O cdc_stream funciona com base em um serviço em segundo plano, e os logs são armazenados por padrão em %APPDATA%\cdc-file-transfer\logs
• Fornece opções de logs detalhados e depuração (configuração JSON de nível de verbosidade)
• O cdc_rsync exibe logs no console, e é possível obter logs detalhados com -vvv e -vvvv
• Facilita rastrear comandos SSH/SFTP que falharam e executá-los diretamente para analisar a causa do problema

Stack técnico e informações operacionais

• A principal linguagem de desenvolvimento é C++, com algum uso de Python/Starlark para build e gerenciamento
• Licença Apache-2.0, mais de 8 contribuidores e 3.3k stars no GitHub
• Desde 2023, está em estado Archived, sem desenvolvimento adicional

Resumo

• CDC File Transfer oferece eficiência e velocidade de nível líder do setor para transferências repetidas de arquivos e diretórios grandes entre Windows e Linux
• Traz grandes ganhos ao encurtar os processos de sincronização e streaming em ambientes de trabalho multiplataforma, como desenvolvimento remoto, jogos, mídia e análise de dados
• Em comparação com outras ferramentas de sincronização/streaming, tem forte competitividade por sua simplicidade, rápida detecção de alterações parciais e excelente cache
• Com autenticação SSH/SFTP e configuração flexível via linha de comando ou arquivos de configuração, pode ser adotado e operado com facilidade por engenheiros
• O código-fonte pode ser consultado e customizado, e o projeto já registra alta reputação e uso na comunidade open source

[GN⁺]

Comentários do Hacker News

• Desde o ano passado venho fazendo vários experimentos com Content Defined Chunking (especialmente no bonanza.build). Descobri que até o algoritmo FastCDC, o mais amplamente usado, ainda tem espaço para melhorias, e que usar uma abordagem de lookahead aumenta bastante o desempenho. Para uma implementação disso, veja buildbarn/go-cdc

  • Essa abordagem de lookahead parece muito com o “lazy matching” em compressores Lempel-Ziv (blog relacionado). Fiquei curioso com os resultados de comparação com Buzhash. Em geral, eu esperaria que gearhash fosse mais rápido por ter uma estrutura mais simples. Aliás, para o gear init, talvez o gerador com seed de rand/v2 seja mais adequado do que mt19937
  • bonanza.build é bem impressionante. Se eu ainda estivesse usando Bazel, com certeza gostaria de experimentar
  • Fico curioso sobre quanta diferença de desempenho haveria ao usar go-cdc no cdc_rsync em vez de fastcdc
  • Isso me faz pensar se a IA teria espaço para contribuir nessa área. A IA já está sendo usada com utilidade em compressão de dados (exemplo de compressão com IA) e otimização de modulação RF (link para o artigo). Imagino que também seria possível treinar um modelo pequeno, especialmente da família SSM, para otimizar os limites dos chunks

• O rsync já não usa limites de chunk definidos por conteúdo com base em condições de rolling hash? (link da wiki 1, link da wiki 2). Suspeito que a melhora de velocidade em relação ao rsync venha da eficiência do rolling hash e do uso de executáveis nativos no Windows (o sistema de arquivos do Windows é lento). De todo modo, o ganho de desempenho é interessante, e o fato de ter virado open source também é positivo. Espero que esse método acabe entrando no próprio rsync

  • O rsync não usa content-defined chunking; ele usa blocos de tamanho fixo no arquivo de destino. Com rolling hash, ele consegue detectar esses blocos em qualquer posição do arquivo de origem e evitar retransmissão (documento técnico)
  • O README do repositório explica de forma muito clara a diferença de abordagem em relação ao rsync
  • O rsync parece, na prática, um projeto parado. Ele é mantido há muito tempo, mas faltam muitas melhorias de qualidade e hoje passa uma impressão parecida com a do vim: teoricamente mantido, mas sem evolução real

• É bom ver que o Stadia deixou mais um benefício de longo prazo desse tipo. Pena que não saiu uma versão self-hosted; no mundo atual de DRM, se saísse, provavelmente seria tratada como pirataria imediatamente

  • Para streaming de jogos self-hosted, a combinação moonlight + sunshine é recomendada. Funciona muito bem
  • Pelo que ouvi, não era possível self-host no Stadia. Os desenvolvedores precisavam fazer um build específico com suporte a Stadia, e talvez fosse até uma plataforma alternativa ao DirectX. Pode ter sido algo como um ambiente leve de emulação, tipo Proton, mas nos jogos que joguei apareciam key bindings customizados do Stadia no próprio jogo (símbolos específicos do Stadia). Havia claramente alguma personalização. Isso o diferencia bastante do streaming de jogos de PlayStation, Xbox e Nvidia. Sobre o Amazon Luna, não sei
  • Para streaming remoto de jogos self-hosted, vale ver Moonlight/Sunshine(Apollo). O Stadia exigia builds dedicados, então não tem muito sentido
  • No fim das contas, o que exatamente significa “pirataria” na era do DRM? Seria fazer streaming pela nuvem de um jogo de PC que você possui?
  • “Stadia self-hosted” na prática já foi implementado por vários serviços e ferramentas. A própria Steam tem um ótimo streaming de jogos embutido. Nvidia e AMD também já colocaram esse recurso nos drivers de GPU, e o Steam Deck também consegue fazer streaming de jogos. Há vários exemplos, como o streaming do PS4/PC da Sony e o streaming do Xbox da Microsoft

• Para quem tinha curiosidade sobre como o Content Defined Chunking realmente gera os chunks, este blog e este blog explicam o conceito de forma bem fácil

  • Valeu. Fiquei frustrado com a falta de explicação detalhada no link original, mas pretendo ler em breve

• Frase principal: "Este algoritmo de diff remoto é baseado em CDC (Content Defined Chunking) e, nos testes, foi até 30 vezes mais rápido que o rsync (1500MB/s contra 50MB/s)"

• Alguém sabe se há algum trabalho em andamento para integrar isso à ferramenta padrão do rsync? Gostaria que esse recurso fosse amplamente usado, mas só de olhar o site oficial já desanima ver que não há suporte nenhum entre Linux e Linux

  • As discussões sobre suporte Linux-Linux e compatibilidade mais genérica estão resumidas aqui 1 e aqui 2

• Também acho esse projeto bem legal. Já implementei algo parecido por conta própria para adaptar ao meu trabalho, e isso pode ser bem importante quando as restrições são complicadas. Ainda assim, fico pensando se não teria sido mais fácil começar a partir do rsync

  • Dizem que “scp só copia arquivos inteiros, não tem modo delta, fica lento com muitos arquivos pequenos e a compressão também é lenta”, mas no rsync dá para usar compressão com a opção -z (explicação). Se houver CPU sobrando, a opção -z é recomendada e também acelera. Talvez não fique extremamente rápido, mas ainda acho que rsync é um ponto de partida melhor que scp
  • “O algoritmo de diff remoto é baseado em CDC e, nos testes, foi até 30 vezes mais rápido que o rsync (1500 MB/s vs 50 MB/s)”
  • Parece que o rsync carece de otimização em algumas áreas, especialmente no desenvolvimento de jogos. Em game dev, é comum copiar dezenas ou centenas de milhões de arquivos e diretórios, e o rsync tende a perder muito desempenho por serializar a criação de diretórios/arquivos. Já tentei dividir em N execuções de rsync com GNU parallel e também gerar a lista de arquivos manualmente, mas no fim resolvi isso com uma ferramenta que faz pré-indexação, como o syncthing

• Fico imaginando se essa técnica poderia ser aplicada ao git. O blob do git gera o hash incluindo informação de tamanho, então se você muda só uma parte dos dados, precisa recalcular o hash desde o começo. Com CDC, isso parece que seria bem mais eficiente

  • No xet, uma abordagem com CDC foi de fato aplicada para substituir o git lfs (caso relacionado)
  • Ferramentas de backup como restic/borg também usam CDC, mas fico curioso se já houve alguma tentativa séria de fazer um substituto do git com isso

• Achei interessante a explicação: “Basta baixar e descompactar o binário precompiled da versão mais recente no Windows. O binário Linux é implantado automaticamente pela ferramenta do Windows em ~/.cache/cdc-file-transfer. Não é necessária instalação separada”. Gosto do fato de que, diferente do rsync, isso funciona sem instalar um serviço separado no destino Linux. Esse aspecto do rsync sempre foi um pouco incômodo

  • Na prática, a forma mais comum de usar rsync é via ssh, iniciando automaticamente o lado receptor no remoto. O cdc funciona da mesma forma, então dizer que o rsync exige instalar um serviço separado é um mal-entendido

• Será que o IBM Aspera funciona de forma parecida? Quando eu trabalhava como QA em uma publicadora de jogos, usávamos Aspera para subir gravações de tela, e ele entregava velocidades muito acima do upload normal da internet do escritório (introdução ao IBM Aspera)