Transfert de fichiers CDC

• CDC File Transfer est un outil open source développé par Google, qui prend en charge la synchronisation et le streaming de fichiers entre Windows et Linux
• Il utilise la technologie Content Defined Chunking (CDC), qui ne transfère que les parties modifiées d’un fichier, et atteint ainsi une vitesse jusqu’à 30 fois supérieure à celle de rsync
• Il propose deux outils principaux, cdc_rsync et cdc_stream, qui assurent respectivement la synchronisation de fichiers et le streaming en temps réel
• Conçu pour permettre aux développeurs travaillant sous Windows de déployer et tester efficacement des fichiers dans un environnement Linux, il se distingue particulièrement dans les environnements de développement à distance et de développement de jeux
• Il prend en charge une authentification basée sur ssh et sftp, son utilisation est intuitive, et des binaires sont fournis pour différentes plateformes

---

Vue d’ensemble et importance du projet

• CDC File Transfer est une suite d’outils de transfert de fichiers publiée en open source par Google, qui gère rapidement et efficacement la synchronisation et le streaming de fichiers entre Windows et Linux ou entre systèmes Windows
• Le projet a été créé pour l’environnement de développement de jeux Stadia, afin de résoudre les limites de scp et de rsync (transferts lents, copie de fichiers complets, absence de mode delta)
• Sa technologie centrale est FastCDC, un algorithme de Content Defined Chunking, optimisé pour les synchronisations répétées de gros volumes en ne transférant que les données réellement modifiées
• Bien qu’open source, il offre des performances de niveau commercial (par exemple une vitesse de synchronisation de 1500 MB/s et un streaming 2 à 5 fois plus rapide que sshfs), avec une efficacité nettement supérieure à celle des services concurrents dans les environnements cloud et de développement à distance

Description des principaux outils

cdc_rsync

• Outil de synchronisation de fichiers de Windows vers Linux, conçu pour dépasser les limites du rsync Linux traditionnel
• Les fichiers dont l’horodatage et la taille correspondent sont ignorés rapidement, et seuls les fichiers modifiés sont transférés efficacement
• Grâce à FastCDC, il détecte et transmet uniquement l’emplacement des données modifiées, offrant un trafic minimal et des transferts rapides
• Les tests de synchronisation montrent des performances environ 3 fois supérieures à celles de rsync exécuté dans Cygwin, et bien plus rapides que le rsync Linux standard
• Il prend en charge la compression rapide et repose sur une structure algorithmique simple mais efficace, capable de vérifier les fichiers jusqu’au niveau de l’octet

cdc_stream

• Permet d’accéder depuis Linux aux dossiers et fichiers Windows en les streamant en temps réel comme s’il s’agissait de fichiers locaux
• Son fonctionnement est similaire à celui de sshfs, mais la vitesse de lecture des fichiers et les performances du cache y sont optimisées
• Grâce à la détection des changements et au streaming différentiel, seules les données modifiées sont retransmises, avec un traitement rapide des métadonnées
• Les répertoires Linux sont fournis en readonly, et les fichiers modifiés sous Windows sont répercutés sous Linux presque immédiatement (au plus en quelques secondes)
• Dans les environnements de développement nécessitant l’accès à de gros fichiers, comme les données de jeu, il offre en pratique des performances 2 à 5 fois supérieures à sshfs

Plateformes prises en charge

• cdc_rsync : principalement pris en charge entre Windows x86_64 et Ubuntu 22.04 x86_64, avec une prise en charge progressive de la synchronisation distante et locale
• cdc_stream : prise en charge du streaming de Windows x86_64 vers Ubuntu 22.04 x86_64 ; la direction inverse ou d’autres plateformes ne sont pas prises en charge

Méthodes d’authentification et de configuration

• Authentification sans mot de passe via ssh.exe et sftp.exe (authentification par clé recommandée)
• Sous Windows, les chemins détaillés des commandes peuvent être indiqués via la ligne de commande ou des variables d’environnement
• Possibilité d’utiliser des options de commande SSH supplémentaires ainsi qu’un fichier de configuration par utilisateur (%USERPROFILE%\\.ssh\\config)
• Pour les utilisateurs internes de Google, des variables d’environnement dédiées sont fournies pour une authentification basée sur des clés de sécurité spécifiques

Exemples d’utilisation

Exemple d’utilisation de cdc_rsync

• Synchronisation d’un fichier : cdc_rsync C:\path\to\file.txt [e-mail]:~
• Prise en charge des jokers et de la synchronisation récursive de répertoires entiers : cdc_rsync C:\path\to\assets\* [e-mail]:~/assets -r
• Vérification en temps réel de l’état de la synchronisation (option -v), avec possibilité de synchroniser aussi entre fichiers locaux

Exemple d’utilisation de cdc_stream

• Démarrer le streaming d’un répertoire : cdc_stream start C:\path\to\assets [e-mail]:~/assets
• Arrêter une session de streaming : cdc_stream stop [e-mail]:~/assets
• Gestion possible de plusieurs sessions à l’aide de jokers

Dépannage et journalisation

• cdc_stream fonctionne comme un service en arrière-plan, et les logs sont enregistrés par défaut dans %APPDATA%\cdc-file-transfer\logs
• Des options de logs détaillés et de débogage sont fournies (configuration JSON du niveau de verbosité)
• cdc_rsync affiche ses logs dans la console, avec des niveaux de détail accessibles via -vvv et -vvvv
• Il est facile de tracer les commandes SSH/SFTP ayant échoué et de les exécuter directement pour analyser la cause d’un problème

Stack technique et informations d’exploitation

• Le langage principal de développement est le C++, avec un peu de Python et de Starlark pour la gestion du build
• Licence Apache-2.0, plus de 8 contributeurs, et 3.3k stars sur GitHub
• Depuis 2023, le projet est en état Archived, sans développement supplémentaire

Résumé

• CDC File Transfer offre une efficacité et une vitesse parmi les meilleures du secteur pour les transferts répétés de gros fichiers et répertoires entre Windows et Linux
• Il permet de réduire fortement les temps de synchronisation et de streaming dans les environnements de travail cross-platform, notamment pour le développement à distance, les jeux, les médias et l’analyse de données
• Par rapport aux autres outils de synchronisation et de streaming, il se distingue par sa simplicité, sa détection rapide des changements partiels et l’excellence de son cache
• Grâce à l’authentification SSH/SFTP et à une configuration souple via la ligne de commande ou des fichiers de configuration, il peut être adopté et exploité facilement par les ingénieurs
• Le code source peut être consulté et personnalisé, et le projet bénéficie déjà d’une excellente réputation et d’un usage important dans la communauté open source

[GN⁺]

Commentaires sur Hacker News

• Depuis l’an dernier, j’expérimente de différentes façons le Content Defined Chunking (en particulier bonanza.build). J’ai constaté qu’il reste des possibilités d’amélioration même pour l’algorithme FastCDC, le plus largement utilisé, et qu’une approche lookahead améliore nettement les performances. Pour une implémentation, voir buildbarn/go-cdc

  • Cette approche lookahead ressemble beaucoup au « lazy matching » des compresseurs Lempel-Ziv (billet de blog associé). Je serais curieux de voir une comparaison avec Buzhash. En général, on s’attend à ce que gearhash soit plus rapide grâce à sa structure plus simple. Au passage, pour l’initialisation de gear, un générateur initialisé de rand/v2 pourrait être plus adapté que mt19937
  • bonanza.build est vraiment impressionnant. Si j’utilisais encore Bazel, j’aurais très envie de l’essayer
  • Je me demande quel écart de performances on obtiendrait en utilisant go-cdc dans cdc_rsync à la place de fastcdc
  • Cela me fait réfléchir à la possibilité pour l’IA d’apporter quelque chose dans ce domaine. L’IA est déjà utilisée utilement pour la compression de données (exemple de compression basée sur l’IA) et pour l’optimisation de la modulation RF (lien vers l’article). J’imagine qu’il serait aussi possible d’entraîner un petit modèle (en particulier de la famille SSM) à optimiser les frontières de chunks

• Est-ce que rsync n’utilise pas déjà des frontières de chunks définies par le contenu en les définissant via des conditions sur rolling hash ? (lien wiki 1, lien wiki 2). Je soupçonne que le gain de vitesse par rapport à rsync vient plutôt de l’efficacité du rolling hash et de l’usage d’un exécutable Windows natif (le système de fichiers Windows étant lent). Quoi qu’il en soit, ce gain de performances est intéressant, et le fait que ce soit open source est un point positif. J’aimerais bien voir cette méthode intégrée à rsync

  • rsync n’utilise pas le content-defined chunking : il travaille avec des blocs de taille fixe sur le fichier de destination. Le rolling hash permet ensuite de détecter ces blocs à n’importe quelle position dans le fichier source afin d’éviter une retransmission (document technique)
  • Le README du dépôt explique très clairement la différence d’approche avec rsync
  • rsync donne en réalité l’impression d’être un projet figé. Il est maintenu depuis longtemps, mais beaucoup d’améliorations de qualité manquent, et cela donne maintenant un peu l’impression de vim : officiellement maintenu, mais sans réelle évolution

• Je trouve sympa que Stadia laisse encore un autre bénéfice à long terme. C’est dommage qu’il n’existe pas de version auto-hébergeable, mais dans le monde actuel du DRM, si elle sortait, elle serait aussitôt considérée comme du piratage

  • Pour le streaming de jeux en auto-hébergement, la combinaison moonlight + sunshine est recommandée. Ça marche très bien
  • J’ai entendu dire que l’auto-hébergement n’était pas possible avec Stadia. Les développeurs devaient produire un build spécifique pour Stadia, et c’était peut-être une plateforme distincte remplaçant DirectX. Cela pouvait aussi être un environnement d’émulation léger comme Proton, mais dans les jeux auxquels j’ai joué, des raccourcis clavier personnalisés propres à Stadia (symboles spécifiques à Stadia) s’affichaient dans le jeu. Il y avait donc clairement une personnalisation. Cette approche se distinguait nettement du streaming de jeux de PlayStation, Xbox et Nvidia. Je ne connais pas bien Amazon Luna
  • Pour le streaming de jeux à distance en auto-hébergement, voir Moonlight/Sunshine (Apollo). Stadia nécessite des builds dédiés, donc l’intérêt est limité
  • Je me demande ce que signifie exactement « piratage » à l’ère du DRM. Est-ce qu’on parle de streamer dans le cloud un jeu PC qu’on possède soi-même ?
  • Un « Stadia auto-hébergé » existe déjà en pratique à travers plusieurs services et outils. Steam intègre lui-même un excellent système de streaming de jeux. Nvidia et AMD ont aussi proposé cette fonction dans leurs pilotes GPU par le passé, et il est possible de streamer des jeux vers le Steam Deck. Il existe aussi divers exemples comme le streaming PS4/PC de Sony ou le streaming Xbox de Microsoft

• Pour ceux qui se demandaient comment le Content Defined Chunking génère concrètement des chunks, ce blog et ce blog expliquent très simplement les concepts

  • Merci. Le lien d’origine manquait d’explications détaillées, ce qui m’a frustré ; je compte lire ça bientôt

• Phrase clé : « Cet algorithme de remote diffing repose sur le CDC (Content Defined Chunking) et, d’après les tests, il est jusqu’à 30 fois plus rapide que rsync (1500MB/s contre 50MB/s) »

• Est-ce que quelqu’un sait s’il y a des travaux en cours pour intégrer cette fonctionnalité à l’outil standard rsync ? J’aimerais qu’elle soit largement utilisée, mais à voir le site officiel, il est dommage qu’il n’y ait aucun support entre Linux et Linux

  • Les discussions sur le support Linux-Linux et sur une compatibilité plus générale sont résumées ici 1, ici 2

• Je trouve aussi ce projet plutôt chouette. J’ai déjà implémenté quelque chose de similaire pour mon travail, adapté à mes besoins, et dans des conditions exigeantes cela peut être assez important. Cela dit, je me demande s’il n’aurait pas été plus simple de partir de rsync

  • Il est dit que « scp ne copie que des fichiers entiers, n’a pas de mode delta, est lent quand il y a beaucoup de petits fichiers, et la compression est lente », mais on peut aussi utiliser la compression dans rsync avec l’option -z (explication). Si le CPU suit, l’option -z est recommandée et améliore aussi la vitesse. Même si ce n’est pas extrêmement rapide, je pense que rsync constitue un meilleur point de départ que scp
  • « L’algorithme de remote diffing repose sur le CDC et, d’après les tests, il est jusqu’à 30 fois plus rapide que rsync (1500 MB/s contre 50 MB/s) »
  • rsync semble manquer d’optimisations dans certains domaines, en particulier le développement de jeux. Dans ce secteur, il faut souvent copier des dizaines ou des centaines de milliers, voire des millions de fichiers et de répertoires, et rsync ralentit fortement à cause de sa tendance à sérialiser la création des répertoires et des fichiers. J’ai essayé de répartir le travail en N tâches rsync avec GNU parallel, ou de générer moi-même des listes de fichiers, mais j’ai fini par résoudre le problème avec un outil comme syncthing, capable de pré-indexer

• Je me demande si cette technologie pourrait aussi s’appliquer à git. Les blobs git sont hachés avec des informations de longueur, donc dès qu’on modifie une partie des données, il faut recalculer le hash depuis le début. Avec le CDC, cela semblerait bien plus efficace

  • Chez xet, une approche CDC a effectivement été utilisée pour remplacer git lfs (cas associé)
  • Les outils de sauvegarde comme restic/borg utilisent aussi le CDC, mais je me demande s’il existe déjà des tentatives sérieuses pour en faire un remplaçant de git

• J’ai trouvé remarquable l’explication suivante : « Il suffit de télécharger et décompresser le binaire précompilé de la dernière version sous Windows. Le binaire Linux est automatiquement déployé depuis l’outil Windows dans ~/.cache/cdc-file-transfer. Aucune installation supplémentaire n’est nécessaire ». Contrairement à rsync, c’est bien de pouvoir fonctionner sans installer de service distinct sur la destination Linux. Cet aspect de rsync m’a toujours paru un peu pénible

  • En pratique, le mode d’utilisation le plus courant de rsync consiste à lancer automatiquement le récepteur distant via ssh. cdc fonctionne de la même façon, donc dire qu’il faut installer un service séparé pour utiliser rsync est un malentendu

• Je me demande si IBM Aspera fonctionne de manière similaire. Quand je travaillais dans la QA chez un éditeur de jeux, j’utilisais Aspera pour téléverser des captures vidéo, et j’obtenais des vitesses bien supérieures au débit d’upload normal du réseau du bureau (présentation d’IBM Aspera)