Transfer File CDC

• CDC File Transfer adalah alat open source yang dikembangkan oleh Google, mendukung sinkronisasi dan streaming file antara Windows dan Linux
• Dengan memanfaatkan teknologi Content Defined Chunking (CDC) yang hanya mengirim bagian yang berubah dari file, alat ini mencapai kecepatan hingga 30 kali lebih cepat dibanding rsync konvensional
• Menyediakan dua alat utama, cdc_rsync dan cdc_stream, yang masing-masing menangani sinkronisasi file dan streaming real-time
• Dirancang agar developer berbasis Windows dapat men-deploy dan menguji file secara efisien di lingkungan Linux, sehingga sangat unggul untuk pengembangan jarak jauh dan lingkungan pengembangan game
• Mendukung autentikasi berbasis ssh dan sftp, mudah digunakan, dan menyediakan binary untuk berbagai platform

---

Gambaran umum dan pentingnya proyek

• CDC File Transfer adalah rangkaian alat transfer file open source yang dirilis Google, untuk menangani sinkronisasi dan streaming file antara Windows ke Linux atau antar-Windows dengan cepat dan efisien
• Proyek ini dibuat untuk lingkungan pengembangan game Stadia, dan lahir untuk mengatasi keterbatasan scp maupun rsync yang ada (transfer lambat, menyalin seluruh file, tidak ada mode delta)
• Teknologi intinya adalah algoritme FastCDC Content Defined Chunking, yang saat file berubah hanya mengirim data yang benar-benar berubah sehingga optimal untuk sinkronisasi berulang berukuran besar
• Meski open source, alat ini menawarkan performa setingkat komersial (misalnya kecepatan sinkronisasi 1500 MB/s, streaming 2~5 kali lebih cepat dibanding sshfs) dan memiliki efisiensi yang jelas lebih tinggi daripada layanan pesaing di lingkungan cloud/pengembangan jarak jauh

Penjelasan alat utama

cdc_rsync

• Alat untuk menyinkronkan file dari Windows ke Linux, sekaligus mengatasi kekurangan rsync Linux konvensional
• File dengan waktu dan ukuran file yang sama dilewati dengan cepat, dan hanya file yang berubah yang ditransfer secara efisien
• Dengan memanfaatkan FastCDC, alat ini mendeteksi dan mengirim hanya lokasi data yang berubah, sehingga menghasilkan trafik minimal dan transfer cepat
• Hasil pengujian sinkronisasi menunjukkan performa sekitar 3 kali lebih cepat daripada rsync yang dijalankan di Cygwin, dan jauh lebih cepat daripada rsync Linux standar
• Mendukung kompresi berkecepatan tinggi serta memiliki struktur algoritme yang sederhana namun efisien untuk memverifikasi file hingga tingkat byte

cdc_stream

• Membuat folder dan file di Windows dapat diakses dari Linux seolah-olah file lokal melalui streaming real-time
• Mirip dengan arsitektur sshfs yang ada, tetapi kecepatan baca file dan performa cache telah dioptimalkan
• Melalui deteksi perubahan dan streaming diferensial, hanya data yang berubah yang dikirim ulang, dan pemrosesan metadata juga cepat
• Direktori Linux disediakan dalam mode readonly, dan file yang diubah di Windows akan tercermin di Linux hampir seketika (maksimal dalam hitungan beberapa detik)
• Dalam lingkungan pengembangan yang membutuhkan akses ke file besar seperti data game, alat ini secara nyata menunjukkan peningkatan performa 2~5 kali dibanding sshfs

Platform yang didukung

• cdc_rsync: terutama mendukung Windows x86_64 ↔ Ubuntu 22.04 x86_64, dengan dukungan sinkronisasi remote/lokal yang terus diperluas
• cdc_stream: mendukung streaming dari Windows x86_64 ke Ubuntu 22.04 x86_64, sedangkan arah sebaliknya atau platform lain tidak didukung

Metode autentikasi/konfigurasi

• Metode autentikasi tanpa kata sandi melalui ssh.exe dan sftp.exe (disarankan autentikasi berbasis kunci)
• Di Windows, detail path command dapat ditentukan melalui command line path atau environment variable
• Dapat memanfaatkan opsi command SSH tambahan dan file konfigurasi per pengguna (%USERPROFILE%\\.ssh\\config)
• Pengguna internal Google mendapatkan environment variable autentikasi berbasis security key terpisah

Contoh penggunaan

Contoh penggunaan cdc_rsync

• Sinkronisasi file: cdc_rsync C:\path\to\file.txt [e-mail]:~
• Mendukung wildcard dan sinkronisasi rekursif seluruh direktori: cdc_rsync C:\path\to\assets\* [e-mail]:~/assets -r
• Status sinkronisasi dapat dipantau secara real-time (opsi -v), dan sinkronisasi antar-file lokal juga dimungkinkan

Contoh penggunaan cdc_stream

• Memulai streaming direktori: cdc_stream start C:\path\to\assets [e-mail]:~/assets
• Menghentikan sesi streaming: cdc_stream stop [e-mail]:~/assets
• Beberapa sesi dapat dikelola dengan wildcard

Pemecahan masalah dan logging

• cdc_stream bekerja berbasis layanan latar belakang, dan log secara default disimpan di path %APPDATA%\cdc-file-transfer\logs
• Menyediakan log detail dan opsi debugging (pengaturan JSON level verbosirty)
• cdc_rsync menampilkan log di konsol, dan log detail dapat ditampilkan dengan -vvv, -vvvv
• Pelacakan command SSH/SFTP yang gagal dan eksekusi langsung memudahkan analisis penyebab masalah

Tech stack dan informasi operasional

• Bahasa pengembangan utama adalah C++, dengan sebagian Python/Starlark untuk pengelolaan build
• Berlisensi Apache-2.0, memiliki lebih dari 8 kontributor, dan telah mencapai 3.3k stars di GitHub
• Sejak 2023, proyek ini berada dalam status Archived tanpa pengembangan tambahan

Ringkasan

• CDC File Transfer memberikan efisiensi dan kecepatan kelas teratas di industri untuk transfer berulang file dan direktori berukuran besar antara Windows dan Linux
• Memberikan keuntungan besar dengan memangkas proses sinkronisasi dan streaming secara signifikan di lingkungan kerja lintas platform seperti pengembangan jarak jauh, game, media, dan analisis data
• Dibanding alat sinkronisasi/streaming lain, alat ini memiliki daya saing kuat berkat kesederhanaan, deteksi perubahan parsial yang cepat, dan kemampuan cache yang unggul
• Dengan autentikasi SSH/SFTP serta konfigurasi fleksibel berbasis command line atau file pengaturan, engineer dapat dengan mudah mengadopsi dan mengoperasikannya
• Kode sumber dapat ditinjau dan dikustomisasi, dan proyek ini sudah mencatat reputasi tinggi serta tingkat pemanfaatan yang baik di komunitas open source

[GN⁺]

Komentar Hacker News

• Sejak tahun lalu saya bereksperimen dengan berbagai hal terkait Content Defined Chunking (terutama bonanza.build). Saya menemukan bahwa bahkan algoritma FastCDC yang paling banyak digunakan pun masih punya ruang untuk ditingkatkan, dan dengan memanfaatkan pendekatan lookahead performanya bisa meningkat secara signifikan. Untuk implementasinya, lihat buildbarn/go-cdc

  • Pendekatan lookahead ini tampak sangat mirip dengan “lazy matching” pada kompresor Lempel-Ziv (blog terkait). Saya penasaran dengan hasil perbandingannya terhadap Buzhash. Biasanya gearhash diperkirakan lebih cepat karena strukturnya lebih sederhana. Sebagai catatan, untuk gear init, seeded generator dari rand/v2 mungkin lebih cocok daripada mt19937
  • bonanza.build sangat mengesankan. Kalau saya masih memakai Bazel, saya pasti ingin mencobanya
  • Saya penasaran seberapa besar perbedaan performanya jika go-cdc dipakai di cdc_rsync alih-alih fastcdc
  • Ini membuat saya berpikir apakah AI punya ruang untuk berkontribusi di bidang ini. AI sudah berguna dalam kompresi data (contoh kompresi berbasis AI) dan optimasi modulasi RF (tautan paper). Saya berharap model kecil, terutama keluarga SSM, mungkin bisa dilatih untuk mengoptimalkan batas chunk

• Bukankah rsync memang sudah menggunakan batas chunk yang ditentukan oleh content melalui kondisi rolling hash? (tautan wiki 1, tautan wiki 2). Saya curiga peningkatan kecepatan dibanding rsync mungkin berasal dari efisiensi rolling hash dan penggunaan executable Windows native (filesystem Windows itu lambat). Bagaimanapun juga, peningkatan performanya menarik, dan fakta bahwa ini sudah di-open-source-kan juga positif. Saya berharap metode ini bisa masuk ke internal rsync juga

  • rsync tidak menggunakan content-defined chunking, melainkan blok berukuran tetap pada file tujuan. Dengan rolling hash, blok tersebut bisa dideteksi di posisi mana pun pada file sumber sehingga pengiriman ulang bisa dihindari (dokumen teknis)
  • README repo itu menjelaskan dengan sangat ramah perbedaan pendekatannya dengan rsync
  • rsync terasa seperti proyek yang praktis mandek. Memang masih dipelihara sudah lama, tetapi banyak peningkatan kualitas yang terlewat, dan sekarang kesannya seperti vim: secara teori masih dikelola, tetapi praktiknya tidak benar-benar berkembang

• Menyenangkan melihat Stadia meninggalkan satu manfaat jangka panjang lagi seperti ini. Saya agak kecewa tidak ada versi self-hosted, tetapi di dunia DRM sekarang ini, kalau ada pun mungkin akan langsung dianggap bajakan

  • Untuk game streaming self-hosted, kombinasi moonlight dan sunshine sangat direkomendasikan. Keduanya bekerja sangat baik
  • Setahu saya Stadia memang tidak bisa di-self-host. Para developer harus membuat build terpisah untuk dukungan Stadia, dan mungkin itu semacam platform pengganti DirectX yang terpisah. Bisa saja itu lingkungan emulasi ringan seperti Proton, tetapi game-game yang saya mainkan benar-benar menampilkan key binding kustom khusus Stadia (simbol khusus Stadia) di dalam game. Jadi jelas ada kustomisasi khusus. Pendekatan ini sangat berbeda dibanding game streaming dari PlayStation, Xbox, atau Nvidia. Saya kurang tahu soal Amazon Luna
  • Untuk remote game streaming self-hosted, lihat Moonlight/Sunshine(Apollo). Stadia memerlukan build khusus terpisah sehingga manfaatnya tidak terlalu besar
  • Di era DRM, saya penasaran apa tepatnya yang dimaksud dengan ‘bajakan’. Apakah maksudnya men-streaming game PC yang Anda miliki sendiri lewat cloud?
  • “Stadia self-hosted” pada praktiknya sebenarnya sudah diwujudkan oleh banyak layanan dan alat. Steam sendiri punya streaming game bawaan yang sangat bagus. Nvidia dan AMD juga dulu pernah memasukkan fungsi itu ke driver GPU mereka, dan game juga bisa di-streaming dari Steam Deck. Ada banyak contoh lain seperti streaming PS4/PC dari Sony atau streaming Xbox dari Microsoft

• Bagi yang penasaran bagaimana sebenarnya Content Defined Chunking membuat chunk, blog ini dan blog ini menjelaskan konsepnya dengan sangat mudah

  • Terima kasih. Saya frustrasi karena penjelasan detail di tautan aslinya kurang, jadi saya berencana membacanya segera

• Kalimat kuncinya: "Algoritma remote diffing ini berbasis CDC(Content Defined Chunking), dan dalam pengujian hasilnya hingga 30 kali lebih cepat daripada rsync (1500MB/s vs 50MB/s)"

• Saya penasaran apakah ada yang tahu jika sedang ada upaya untuk mengintegrasikan fitur ini ke tool standar rsync. Saya ingin ini dipakai luas, tetapi kalau melihat situs resminya saja rasanya sayang karena antar Linux sama sekali belum didukung

  • Diskusi tentang dukungan Linux-ke-Linux dan kompatibilitas yang lebih umum dirangkum di sini 1, di sini 2

• Menurut saya proyek ini juga cukup keren. Saya pernah mengimplementasikan sendiri fitur serupa agar sesuai dengan pekerjaan saya, dan saat syaratnya rumit hal seperti ini cukup penting. Tapi saya tetap berpikir, bukankah akan lebih mudah kalau memulai dari rsync?

  • Dikatakan bahwa “scp hanya menyalin seluruh file, tidak punya mode delta, lambat jika file kecilnya banyak, dan kompresinya juga lambat”, tetapi di rsync kita juga bisa memakai kompresi dengan opsi -z (penjelasan). Kalau CPU memadai, opsi -z direkomendasikan dan kecepatannya juga meningkat. Mungkin tidak super cepat, tetapi menurut saya rsync tetap titik awal yang lebih baik daripada scp
  • “Algoritma remote diffing berbasis CDC, dan hasil pengujian menunjukkan performa hingga 30 kali lebih cepat daripada rsync (1500 MB/s vs 50 MB/s)”
  • Tampaknya rsync memang kurang optimal di beberapa bidang, terutama game development. Dalam game development sering ada situasi menyalin puluhan ribu hingga jutaan file dan direktori, dan rsync cenderung menurun drastis karena proses pembuatan direktori/file yang terserialisasi. Saya pernah mencoba membaginya menjadi N pekerjaan rsync dengan GNU parallel dan juga menjalankannya dengan daftar file buatan sendiri, tetapi akhirnya saya menyelesaikannya dengan tool yang bisa melakukan pre-indexing seperti syncthing

• Saya penasaran apakah teknik ini juga bisa diterapkan ke git. Git blob membuat hash dengan menyertakan informasi panjang, jadi kalau hanya sebagian data berubah pun hash harus dihitung ulang dari awal. Dengan CDC sepertinya akan jauh lebih efisien

  • Di xet, pendekatan CDC memang benar-benar diterapkan untuk menggantikan git lfs (contoh terkait)
  • Tool backup seperti restic/borg juga memakai CDC, tetapi saya penasaran apakah sudah ada upaya yang benar-benar matang untuk pengganti git

• Saya terkesan dengan penjelasan, “Cukup unduh dan ekstrak binary precompiled dari rilis terbaru di Windows. Binary Linux akan otomatis dideploy ke ~/.cache/cdc-file-transfer dari tool Windows. Tidak perlu instalasi terpisah.” Tidak seperti rsync, ini bagus karena bisa berjalan tanpa memasang layanan tambahan di tujuan Linux. Bagian seperti ini di rsync agak merepotkan

  • Sebenarnya cara paling umum memakai rsync adalah menjalankan sisi penerima secara otomatis lewat ssh di remote. cdc juga bekerja dengan cara yang sama, jadi anggapan bahwa rsync memerlukan pemasangan layanan terpisah itu adalah kesalahpahaman

• Saya penasaran apakah IBM Aspera juga bekerja dengan cara yang mirip. Saat bekerja sebagai QA publisher game, saya pernah mengunggah rekaman layar dengan Aspera, dan kecepatannya jauh melampaui kecepatan upload internet normal kantor (pengenalan IBM Aspera)