CDC-Dateiübertragung

• CDC File Transfer ist ein von Google entwickeltes Open-Source-Tool, das Dateisynchronisierung und Streaming zwischen Windows und Linux unterstützt
• Es nutzt die Content Defined Chunking (CDC)-Technologie, die nur geänderte Teile einer Datei überträgt, und erreicht damit im Vergleich zu herkömmlichem rsync bis zu 30-mal höhere Geschwindigkeiten
• Es bietet zwei zentrale Werkzeuge, cdc_rsync und cdc_stream, die jeweils Dateisynchronisierung und Echtzeit-Streaming übernehmen
• Es wurde dafür entwickelt, dass Windows-basierte Entwickler Dateien effizient in Linux-Umgebungen bereitstellen und testen können, und ist daher besonders stark in Remote-Development- und Game-Development-Umgebungen
• Unterstützt ssh- und sftp-basierte Authentifizierung, ist intuitiv nutzbar und stellt Binärdateien für verschiedene Plattformen bereit

---

Überblick und Bedeutung des Projekts

• CDC File Transfer ist eine von Google als Open Source veröffentlichte Sammlung von Dateiübertragungswerkzeugen, die Dateisynchronisierung und Streaming zwischen Windows und Linux oder zwischen Windows-Systemen schnell und effizient verarbeitet
• Das Projekt wurde für die Stadia-Spielentwicklungsumgebung entwickelt und entstand, um die Grenzen von scp und rsync (langsame Übertragung, vollständiges Kopieren von Dateien, fehlender Delta-Modus) zu überwinden
• Die Kerntechnologie ist der FastCDC-Algorithmus für Content Defined Chunking, der bei Dateiänderungen nur die tatsächlich geänderten Daten überträgt und damit für wiederholte Synchronisierung großer Datenmengen optimiert ist
• Trotz Open Source bietet es Performance auf kommerziellem Niveau (z. B. 1500 MB/s Synchronisierungsgeschwindigkeit, 2- bis 5-mal schnelleres Streaming als sshfs) und weist in Cloud- und Remote-Development-Umgebungen eine deutlich höhere Effizienz als konkurrierende Dienste auf

Beschreibung der wichtigsten Werkzeuge

cdc_rsync

• Ein Werkzeug zur Dateisynchronisierung von Windows nach Linux, das die Schwächen des bestehenden Linux-rsync überwindet
• Dateien mit übereinstimmender Zeit und Dateigröße werden schnell übersprungen, und nur geänderte Dateien werden effizient übertragen
• Mit FastCDC wird nur die Position geänderter Daten erkannt und übertragen, was minimalen Traffic und schnelle Transfers ermöglicht
• Synchronisationstests zeigen eine etwa dreimal höhere Leistung als unter Cygwin ausgeführtes rsync sowie deutlich bessere Performance als Standard-Linux-rsync
• Es unterstützt schnelle Komprimierung und verfügt über eine einfache, aber effiziente Algorithmusstruktur, die Dateien bis auf Byte-Ebene verifiziert

cdc_stream

• Macht Ordner und Dateien unter Windows in Linux per Echtzeit-Streaming so zugänglich, als wären sie lokale Dateien
• Ähnelt strukturell sshfs, ist aber bei Dateilesegeschwindigkeit und Cache-Performance optimiert
• Durch Änderungserkennung und differenzielles Streaming werden nur geänderte Daten erneut übertragen, auch Metadaten werden schnell verarbeitet
• Linux-Verzeichnisse werden schreibgeschützt bereitgestellt; unter Windows geänderte Dateien werden nahezu sofort (innerhalb von bis zu wenigen Sekunden) in Linux übernommen
• In Entwicklungsumgebungen, die Zugriff auf große Dateien wie Spieldaten benötigen, zeigt es in der Praxis eine 2- bis 5-mal bessere Performance als sshfs

Unterstützte Plattformen

• cdc_rsync: hauptsächlich unterstützt zwischen Windows x86_64 ↔ Ubuntu 22.04 x86_64, Unterstützung für Remote-Synchronisierung und lokale Synchronisierung wird schrittweise erweitert
• cdc_stream: unterstützt Streaming von Windows x86_64 nach Ubuntu 22.04 x86_64, die Gegenrichtung oder andere Plattformen werden nicht unterstützt

Authentifizierungs- und Konfigurationsmethoden

• Passwortlose Authentifizierung über ssh.exe und sftp.exe (schlüsselbasierte Authentifizierung empfohlen)
• Unter Windows können detaillierte Pfade zu Befehlen per Kommandozeile oder Umgebungsvariablen angegeben werden
• Zusätzliche SSH-Befehlsoptionen und benutzerspezifische Konfigurationsdateien (%USERPROFILE%\.ssh\config) können verwendet werden
• Für interne Google-Nutzer stehen Umgebungsvariablen für eine separate sicherheitsschlüsselbasierte Authentifizierungsumgebung bereit

Nutzungsbeispiele

Beispiele für cdc_rsync

• Dateisynchronisierung: cdc_rsync C:\path\to\file.txt [e-mail]:~
• Unterstützung für Wildcards und rekursive Synchronisierung ganzer Verzeichnisse: cdc_rsync C:\path\to\assets\* [e-mail]:~/assets -r
• Echtzeitprüfung des Synchronisierungsstatus (Option -v), Synchronisierung auch zwischen lokalen Dateien möglich

Beispiele für cdc_stream

• Starten des Verzeichnis-Streamings: cdc_stream start C:\path\to\assets [e-mail]:~/assets
• Beenden einer Streaming-Sitzung: cdc_stream stop [e-mail]:~/assets
• Verwaltung mehrerer Sitzungen per Wildcard möglich

Fehlerbehebung und Logging

• cdc_stream arbeitet auf Basis eines Hintergrunddienstes; Logs werden standardmäßig unter %APPDATA%\cdc-file-transfer\logs gespeichert
• Detaillierte Logs und Debugging-Optionen werden bereitgestellt (JSON-Konfiguration mit verbosity-Level)
• cdc_rsync gibt Konsolenlogs aus, detaillierte Logs sind mit -vvv und -vvvv möglich
• Fehlgeschlagene SSH-/SFTP-Befehle lassen sich nachverfolgen und direkt ausführen, was die Ursachenanalyse erleichtert

Technologie-Stack und Betriebsinformationen

• Die wichtigste Entwicklungssprache ist C++, teilweise kommen Python sowie Starlark für das Build-Management zum Einsatz
• Apache-2.0-Lizenz, mehr als 8 Mitwirkende, auf GitHub 3,3k Stars erreicht
• Seit 2023 ohne weitere Entwicklung im Archived-Status

Zusammenfassung

• CDC File Transfer bietet bei wiederholter Übertragung großer Dateien und Verzeichnisse zwischen Windows und Linux Effizienz und Geschwindigkeit auf Spitzenniveau
• In plattformübergreifenden Arbeitsumgebungen wie Remote Development, Games, Medien und Datenanalyse verkürzt es Synchronisierungs- und Streaming-Prozesse erheblich
• Im Vergleich zu anderen Synchronisierungs- und Streaming-Tools besitzt es durch Einfachheit, schnelle Erkennung partieller Änderungen und starke Cache-Funktionen eine hohe Wettbewerbsfähigkeit
• Dank SSH-/SFTP-Authentifizierung sowie flexibler Umgebungsanpassung über Kommandozeile oder Konfigurationsdateien können Engineers es leicht einführen und betreiben
• Der Quellcode kann eingesehen und angepasst werden; in der Open-Source-Community hat das Projekt bereits einen hohen Ruf und eine breite Nutzung erreicht

[GN⁺]

Hacker-News-Kommentare

• Ich experimentiere seit letztem Jahr auf verschiedene Weise mit Content Defined Chunking (insbesondere bonanza.build). Dabei habe ich festgestellt, dass selbst beim am weitesten verbreiteten FastCDC-Algorithmus noch Raum für Verbesserungen besteht und dass sich die Leistung mit einem Lookahead-Ansatz deutlich steigern lässt. Eine Implementierung dazu findet sich unter buildbarn/go-cdc

  • Dieser Lookahead-Ansatz wirkt dem „lazy matching“ in Lempel-Ziv-Kompressoren sehr ähnlich (zugehöriger Blog). Mich würden Vergleichsergebnisse mit Buzhash interessieren. Normalerweise würde ich erwarten, dass gearhash wegen seiner einfacheren Struktur schneller ist. Für gear init könnte übrigens ein seeded generator aus rand/v2 geeigneter sein als mt19937
  • bonanza.build ist ziemlich beeindruckend. Wenn ich noch Bazel verwenden würde, würde ich das unbedingt ausprobieren wollen
  • Ich frage mich, wie groß der Leistungsunterschied wäre, wenn man go-cdc statt fastcdc in cdc_rsync einsetzen würde
  • Das bringt mich zum Nachdenken, ob KI in diesem Bereich etwas beitragen könnte. KI wird bereits sinnvoll bei Datenkompression (Beispiel für KI-basierte Kompression) und bei der Optimierung von RF-Modulation (Paper-Link) eingesetzt. Ich könnte mir vorstellen, dass man ein kleines Modell, insbesondere aus der SSM-Familie, trainieren könnte, um Chunk-Grenzen zu optimieren

• Nutzt rsync nicht bereits Content-Defined-Chunk-Grenzen, die über eine Rolling-Hash-Bedingung definiert sind? (Wiki-Link 1, Wiki-Link 2). Ich vermute, dass die Geschwindigkeitsverbesserung gegenüber rsync eher an der Effizienz des Rolling Hashs und daran liegt, dass native Windows-Binärdateien verwendet werden (das Windows-Dateisystem ist langsam). Trotzdem ist der Performancegewinn interessant, und auch dass es Open Source ist, ist positiv. Hoffentlich findet diese Methode auch ihren Weg in rsync

  • rsync verwendet kein Content-Defined Chunking, sondern Blöcke fester Größe auf der Zieldatei. Mit einem Rolling Hash kann dann an beliebigen Positionen in der Quelldatei erkannt werden, dass ein solcher Block bereits vorhanden ist, sodass eine erneute Übertragung vermieden wird (technisches Dokument)
  • Im README des Repos wird der Unterschied zum rsync-Ansatz sehr verständlich erklärt
  • rsync fühlt sich inzwischen wie ein faktisch eingefrorenes Projekt an. Es wird zwar seit Langem gepflegt, aber viele Qualitätsverbesserungen fehlen, und inzwischen wirkt es fast wie vim: theoretisch gepflegt, praktisch ohne Weiterentwicklung

• Es freut mich, dass Stadia auf diese Weise noch einen weiteren langfristigen Nutzen hinterlassen hat. Schade, dass keine Self-Hosting-Version erschienen ist, aber in der heutigen DRM-Welt würde sie, falls sie käme, wohl sofort als Piraterie abgestempelt werden

  • Für selbst gehostetes Game-Streaming werden moonlight und sunshine zusammen empfohlen. Das funktioniert sehr gut
  • Soweit ich weiß, war Self-Hosting bei Stadia nicht möglich. Entwickler mussten den Support für Stadia separat bauen, und es könnte eine eigene DirectX-Ersatzplattform gewesen sein. Vielleicht war es auch eher eine schlanke Emulationsumgebung wie Proton, aber in den Spielen, die ich tatsächlich gespielt habe, wurden im Spiel eigene benutzerdefinierte Tastenbelegungen für Stadia angezeigt (Stadia-spezifische Symbole). Es gab also eindeutig Anpassungen. Das unterscheidet sich deutlich vom Game-Streaming bei PlayStation, Xbox und Nvidia. Bei Amazon Luna bin ich mir nicht sicher
  • Für selbst gehostetes Remote-Game-Streaming siehe Moonlight/Sunshine (Apollo). Stadia ist ohne separate dedizierte Builds nicht besonders relevant
  • Ich frage mich, was „Piraterie“ im DRM-Zeitalter eigentlich genau bedeuten soll. Ist damit gemeint, eigene PC-Spiele per Cloud zu streamen?
  • „Self-hosted Stadia“ ist im Grunde bereits in verschiedenen Diensten und Tools umgesetzt worden. Steam selbst hat hervorragendes Game-Streaming eingebaut. Nvidia und AMD hatten diese Funktion früher auch in ihren GPU-Treibern, und auch auf dem Steam Deck kann man Spiele streamen. Es gibt viele weitere Beispiele, etwa das Streaming von Sony auf PS4/PC oder von Microsoft auf Xbox

• Falls sich jemand gefragt hat, wie Content Defined Chunking in der Praxis tatsächlich Chunks erzeugt: dieser Blog und dieser Blog erklären das Konzept sehr anschaulich

  • Danke. Im ursprünglichen Link fehlte mir eine ausführliche Erklärung, was frustrierend war, aber ich plane, das bald zu lesen

• Kernsatz: „Dieser Remote-Diffing-Algorithmus basiert auf CDC (Content Defined Chunking) und ist in Tests bis zu 30-mal schneller als rsync (1500MB/s gegenüber 50MB/s)“

• Ich würde gern wissen, ob an einer Integration dieser Funktion in das Standardwerkzeug rsync gearbeitet wird. Es wäre schön, wenn das breit genutzt würde, aber der offiziellen Website nach scheint es zwischen Linux und Linux gar nicht unterstützt zu werden

  • Diskussionen über Linux-zu-Linux-Unterstützung und allgemeinere Kompatibilität sind hier 1 und hier 2 zusammengefasst

• Ich finde auch dieses Projekt ziemlich cool. Ich habe einmal etwas mit ähnlicher Funktionalität für meine Arbeit selbst implementiert, und unter schwierigen Bedingungen ist so etwas ziemlich wichtig. Trotzdem frage ich mich, ob es nicht einfacher gewesen wäre, von rsync aus zu starten

  • Es heißt zwar, „scp kopiert nur ganze Dateien, hat keinen Delta-Modus, ist bei vielen kleinen Dateien langsam, und Kompression ist ebenfalls langsam“, aber bei rsync kann man Kompression mit der Option -z verwenden (Erklärung). Wenn genug CPU vorhanden ist, würde ich -z empfehlen, und es wird auch schneller. Vielleicht nicht extrem schnell, aber ich denke, rsync wäre trotzdem ein besserer Ausgangspunkt als scp
  • „Der Remote-Diffing-Algorithmus basiert auf CDC und ist in Tests bis zu 30-mal schneller als rsync (1500 MB/s vs. 50 MB/s)“
  • rsync scheint in manchen Bereichen, besonders in der Spieleentwicklung, nicht gut optimiert zu sein. Dort muss man oft zehntausende bis millionenweise Dateien und Verzeichnisse kopieren, und rsync wird wegen seiner Tendenz, das Erstellen von Verzeichnissen und Dateien zu serialisieren, stark ausgebremst. Ich habe versucht, das mit GNU parallel in N rsync-Jobs aufzuteilen oder Dateilisten direkt zu erzeugen, aber am Ende habe ich das Problem mit einem Tool gelöst, das Vorab-Indizierung beherrscht, etwa syncthing

• Ich frage mich, ob sich diese Technik auch auf git anwenden ließe. Git-Blobs bilden ihren Hash unter Einbeziehung der Längeninformation, daher muss bei jeder noch so kleinen Datenänderung der Hash von Anfang an neu berechnet werden. Mit CDC wäre das vermutlich viel effizienter

  • Bei xet wurde ein CDC-Ansatz tatsächlich eingesetzt, um git lfs zu ersetzen (zugehöriger Fall)
  • Auch Backup-Tools wie restic/borg verwenden CDC, aber ich frage mich, ob es bereits ernsthafte Versuche als Ersatz für git gibt

• Die Erklärung „Lade einfach das vorkompilierte Binary des neuesten Releases unter Windows herunter und entpacke es. Das Linux-Binary wird vom Windows-Tool automatisch nach ~/.cache/cdc-file-transfer verteilt. Es ist keine zusätzliche Installation erforderlich“ fand ich beeindruckend. Im Gegensatz zu rsync funktioniert es ohne Installation eines separaten Dienstes auf dem Linux-Zielsystem. Das war bei rsync immer etwas umständlich

  • Tatsächlich ist die häufigste Nutzungsweise von rsync, dass über ssh auf dem Zielsystem automatisch die empfangende Seite gestartet wird. cdc funktioniert auf die gleiche Weise, daher ist die Aussage, rsync brauche dafür einen separat installierten Dienst, ein Missverständnis

• Ich frage mich, ob IBM Aspera auf ähnliche Weise arbeitet. Als ich als QA bei einem Spiele-Publisher gearbeitet habe, habe ich Bildschirmaufzeichnungen mit Aspera hochgeladen, und das war deutlich schneller als die normale Upload-Geschwindigkeit des Büro-Internets (IBM Aspera Einführung)