Transferencia de archivos CDC

• CDC File Transfer es una herramienta de código abierto desarrollada por Google que permite la sincronización y el streaming de archivos entre Windows y Linux
• Aprovecha la tecnología Content Defined Chunking (CDC), que transfiere solo las partes modificadas de un archivo, logrando velocidades de hasta 30 veces más rápidas que rsync
• Ofrece dos herramientas principales: cdc_rsync y cdc_stream, que realizan funciones de sincronización de archivos y streaming en tiempo real, respectivamente
• Está diseñada para que los desarrolladores que trabajan en Windows puedan desplegar y probar archivos de forma eficiente en entornos Linux, por lo que destaca en desarrollo remoto y entornos de desarrollo de videojuegos
• Soporta autenticación basada en ssh y sftp, es fácil de usar y ofrece binarios para distintas plataformas

---

Descripción general e importancia del proyecto

• CDC File Transfer es un conjunto de herramientas de transferencia de archivos publicado como código abierto por Google, que procesa de forma rápida y eficiente la sincronización y el streaming de archivos entre Windows y Linux, o entre equipos Windows
• Este proyecto fue creado para el entorno de desarrollo de juegos de Stadia, y surgió para resolver las limitaciones de scp y rsync existentes (transferencia lenta, copia completa de archivos, ausencia de modo delta)
• Su tecnología central es FastCDC, un algoritmo de Content Defined Chunking, optimizado para sincronizaciones repetidas de archivos grandes al transferir solo los datos realmente modificados cuando un archivo cambia
• Aunque es de código abierto, ofrece un rendimiento de nivel comercial (por ejemplo, velocidad de sincronización de 1500 MB/s y streaming entre 2 y 5 veces más rápido que sshfs), con una eficiencia claramente superior a la de servicios competidores en entornos de nube y desarrollo remoto

Descripción de las herramientas principales

cdc_rsync

• Es una herramienta para sincronizar archivos de Windows a Linux, y supera las desventajas del rsync tradicional de Linux
• Omite rápidamente los archivos cuyo tiempo y tamaño coinciden, y transfiere de manera eficiente solo los archivos modificados
• Con FastCDC, detecta y transmite únicamente la ubicación de los datos modificados, ofreciendo tráfico mínimo y transferencias rápidas
• En pruebas de sincronización, mostró un rendimiento aproximadamente 3 veces superior al de rsync ejecutado en Cygwin, y mucho más rápido que el rsync estándar de Linux
• Cuenta con soporte de compresión de alta velocidad y una estructura algorítmica simple pero eficiente que verifica los archivos hasta el nivel de bytes

cdc_stream

• Permite acceder desde Linux a carpetas y archivos de Windows como si fueran archivos locales, mediante streaming en tiempo real
• Su estructura es similar a la de sshfs, pero tiene optimizados la velocidad de lectura de archivos y el rendimiento de la caché
• Mediante detección de cambios y streaming diferencial, retransmite solo los datos modificados y también procesa rápidamente los metadatos
• Los directorios en Linux se ofrecen en modo readonly, y los archivos modificados en Windows se reflejan en Linux casi de inmediato (como máximo en unos pocos segundos)
• En entornos de desarrollo que requieren acceso a archivos grandes, como datos de juegos, ha mostrado en la práctica mejoras de rendimiento de entre 2 y 5 veces frente a sshfs

Plataformas compatibles

• cdc_rsync: compatibilidad principal entre Windows x86_64 ↔ Ubuntu 22.04 x86_64, con soporte gradual tanto para sincronización remota como local
• cdc_stream: soporte de streaming desde Windows x86_64 hacia Ubuntu 22.04 x86_64; no admite la dirección inversa ni otras plataformas

Método de autenticación/configuración

• Método de autenticación sin contraseña mediante ssh.exe y sftp.exe (se recomienda autenticación basada en claves)
• En Windows se pueden especificar rutas detalladas de comandos mediante la línea de comandos o variables de entorno
• Se pueden usar opciones adicionales de comandos SSH y archivos de configuración por usuario (%USERPROFILE%\.ssh\config)
• Para usuarios internos de Google, se proporcionan variables de entorno para autenticación basada en claves de seguridad independientes

Ejemplos de uso

Ejemplos de uso de cdc_rsync

• Sincronización de archivos: cdc_rsync C:\path\to\file.txt [e-mail]:~
• Soporta comodines y sincronización recursiva de directorios completos: cdc_rsync C:\path\to\assets\* [e-mail]:~/assets -r
• También permite ver el estado de sincronización en tiempo real (opción -v) y sincronizar entre archivos locales

Ejemplos de uso de cdc_stream

• Iniciar streaming de directorio: cdc_stream start C:\path\to\assets [e-mail]:~/assets
• Detener una sesión de streaming: cdc_stream stop [e-mail]:~/assets
• Se pueden administrar varias sesiones con comodines

Solución de problemas y registros

• cdc_stream funciona sobre la base de un servicio en segundo plano; los registros se guardan por defecto en %APPDATA%\cdc-file-transfer\logs
• Ofrece opciones de registros detallados y depuración (configuración JSON del nivel de verbosidad)
• cdc_rsync muestra registros en la consola, y permite salida detallada con -vvv y -vvvv
• Es fácil rastrear comandos SSH/SFTP fallidos y ejecutarlos directamente para analizar la causa del problema

Stack tecnológico e información operativa

• El lenguaje principal de desarrollo es C++, con algo de Python/Starlark para compilación y gestión de builds
• Licencia Apache-2.0, más de 8 colaboradores y 3.3k stars en GitHub
• Desde 2023 no ha habido desarrollo adicional y el proyecto está en estado Archived

Resumen

• CDC File Transfer ofrece eficiencia y velocidad de primer nivel en la industria para la transferencia repetida de archivos y directorios grandes entre Windows y Linux
• Tiene la ventaja de acortar considerablemente los procesos de sincronización y streaming en entornos de trabajo multiplataforma, como desarrollo remoto, videojuegos, medios y análisis de datos
• Frente a otras herramientas de sincronización/streaming, destaca por su simplicidad, rápida detección de cambios parciales y excelente caché, lo que le da una fuerte competitividad
• Con autenticación SSH/SFTP y una configuración flexible basada en línea de comandos o archivos de configuración, los ingenieros pueden adoptarlo y operarlo fácilmente
• Permite revisar y personalizar el código fuente, y ya registra una alta reputación y uso dentro de la comunidad de código abierto

[GN⁺]

Opiniones de Hacker News

• Desde el año pasado he estado experimentando bastante con Content Defined Chunking (especialmente bonanza.build). Descubrí que incluso el algoritmo FastCDC, que es el más usado, todavía tiene margen de mejora, y que usar un enfoque de lookahead mejora mucho el rendimiento. Como implementación de esto, vale la pena revisar buildbarn/go-cdc

  • Este enfoque de lookahead se ve muy parecido al “lazy matching” de los compresores Lempel-Ziv (blog relacionado). Me da curiosidad ver una comparación con Buzhash. Normalmente esperaría que gearhash fuera más rápido por su estructura más simple. Por cierto, para gear init quizá sea más apropiado usar el generador con semilla de rand/v2 en lugar de mt19937
  • bonanza.build es bastante impresionante. Si todavía estuviera usando Bazel, sin duda lo probaría
  • Me pregunto qué tanta diferencia de rendimiento habría al usar go-cdc en cdc_rsync en lugar de fastcdc
  • Esto me hace pensar si la IA podría aportar algo en esta área. La IA ya se está usando con buenos resultados en compresión de datos (caso de compresión con IA), optimización de modulación RF (enlace al paper), etc. Espero que también sea posible entrenar un modelo pequeño (especialmente de la familia SSM) para optimizar los límites de los chunks

• ¿No usa rsync ya límites de chunks definidos por contenido mediante una condición de rolling hash? (wiki 1, wiki 2). Sospecho que la mejora frente a rsync podría deberse a la eficiencia del rolling hash y al uso de ejecutables nativos en Windows (el sistema de archivos de Windows es lento). De todos modos, la mejora de rendimiento es interesante, y también es positivo que se haya liberado como open source. Ojalá este método también termine entrando a rsync

  • rsync no usa content-defined chunking, sino bloques de tamaño fijo sobre el archivo de destino. Usa rolling hash para detectar esos bloques en cualquier posición del archivo fuente y así evitar retransmitirlos (documentación técnica)
  • El README del repo explica de forma muy clara la diferencia de enfoque con rsync
  • rsync da la impresión de ser un proyecto prácticamente estancado. Se ha mantenido por mucho tiempo, pero le faltan muchas mejoras de calidad, y ahora da una sensación parecida a vim: en teoría sigue mantenido, pero en la práctica no parece avanzar

• Me da gusto ver que Stadia dejó otra ganancia a largo plazo como esta. Es una pena que no haya una versión self-hosted, aunque en el mundo actual del DRM, si existiera, enseguida la tratarían como piratería

  • Para game streaming self-hosted se recomienda la combinación de moonlight y sunshine. Funciona muy bien
  • Según entiendo, Stadia no podía self-hostearse directamente. Los desarrolladores tenían que hacer un build aparte con soporte para Stadia, y quizá incluso era una plataforma distinta en lugar de solo un reemplazo de DirectX. Tal vez era un entorno de emulación ligero como Proton, pero los juegos que jugué en Stadia mostraban dentro del juego key bindings personalizados para Stadia (símbolos exclusivos de Stadia). Claramente había personalización real. Eso lo diferencia bastante del game streaming de PlayStation, Xbox y Nvidia. De Amazon Luna no sé mucho
  • Para remote game streaming self-hosted, revisa Moonlight/Sunshine(Apollo). Stadia requiere builds dedicados por separado, así que no tiene mucho sentido
  • En la era del DRM, me pregunto qué significa exactamente “piratería”. ¿Se refiere a hacer streaming en la nube de juegos de PC que ya posees?
  • En la práctica, un “self-hosted Stadia” ya se ha implementado en varios servicios y herramientas. Steam ya trae integrado un muy buen sistema de game streaming. Nvidia y AMD también llegaron a incluir esa función en sus drivers de GPU, y en Steam Deck también se puede hacer streaming de juegos. Hay muchos ejemplos, como el streaming de Sony para PS4/PC o el de Xbox de Microsoft

• Para quien tenga curiosidad sobre cómo Content Defined Chunking genera realmente los chunks, este blog y este blog explican el concepto de forma muy sencilla

  • Gracias. El enlace original me dejó frustrado porque no explicaba mucho en detalle, pero planeo leer estos pronto

• Frase clave: "Este algoritmo de remote diffing se basa en CDC (Content Defined Chunking) y, según las pruebas, es hasta 30 veces más rápido que rsync (1500MB/s frente a 50MB/s)"

• Me pregunto si alguien sabe si ya hay trabajo en curso para integrar esta función en la herramienta estándar rsync. Me gustaría que se usara ampliamente, pero por lo que se ve en el sitio oficial, ni siquiera hay soporte entre Linux y Linux, lo cual es una lástima

  • La discusión sobre soporte Linux-Linux y compatibilidad más general está resumida aquí 1, aquí 2

• Este proyecto también me parece bastante genial. Una vez implementé algo parecido por mi cuenta para adaptarlo a mi trabajo, y cuando las condiciones son complicadas puede ser bastante importante. Aun así, me queda la duda de si no habría sido más fácil partir desde rsync

  • Se dice que “scp solo copia archivos completos, no tiene modo delta, y si hay muchos archivos pequeños es lento, además de que la compresión también es lenta”, pero en rsync se puede usar compresión con la opción -z (explicación). Si tienes suficiente CPU, se recomienda usar -z y también mejora la velocidad. Aunque no sea rapidísimo, me parece que rsync sigue siendo un mejor punto de partida que scp
  • “El algoritmo de remote diffing se basa en CDC y, según las pruebas, es hasta 30 veces más rápido que rsync (1500 MB/s vs 50 MB/s)”
  • Parece que rsync no está bien optimizado para ciertos casos, especialmente en desarrollo de videojuegos. En game dev es común copiar decenas o cientos de miles, e incluso millones, de archivos y directorios, y rsync tiende a degradarse mucho porque serializa la creación de directorios y archivos. Probé dividirlo en N procesos de rsync con GNU parallel y también generar listas de archivos manualmente, pero al final lo resolví con una herramienta como syncthing, que permite preindexación

• Me pregunto si esta técnica podría aplicarse también a git. Los blobs de git generan su hash incluyendo la información de longitud, así que si cambias solo una parte de los datos, hay que volver a calcular el hash desde cero. Con CDC parecería mucho más eficiente

  • En xet ya se aplicó un enfoque basado en CDC para reemplazar git lfs (caso relacionado)
  • Herramientas de backup como restic/borg también usan CDC, pero me pregunto si ya existe algún intento serio de usarlo como reemplazo de git

• Me impresionó la explicación: “Solo hay que descargar y descomprimir los binarios precompiled del release más reciente en Windows. El binario de Linux se despliega automáticamente desde la herramienta de Windows a ~/.cache/cdc-file-transfer. No hace falta instalación adicional”. A diferencia de rsync, me gusta que funcione sin instalar un servicio aparte en el destino Linux. Ese aspecto de rsync siempre me había parecido algo incómodo

  • En realidad, la forma más común de usar rsync es que ejecute automáticamente el lado receptor remoto mediante ssh. cdc funciona igual, así que es un malentendido pensar que para usar rsync hace falta instalar un servicio aparte

• Me pregunto si IBM Aspera funciona de forma parecida. Cuando trabajaba como QA para una publicadora de videojuegos, subía grabaciones de pantalla con Aspera y mostraba velocidades muy por encima de la subida normal del internet de la oficina (introducción a IBM Aspera)