CDC फ़ाइल ट्रांसफ़र

 (github.com/google)
2 पॉइंट द्वारा GN⁺ 2025-10-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CDC File Transfer Google द्वारा विकसित एक open source टूल है, जो Windows और Linux के बीच फ़ाइल सिंक्रोनाइज़ेशन और स्ट्रीमिंग को सपोर्ट करता है
  • यह फ़ाइल के सिर्फ़ बदले हुए हिस्से भेजने वाली Content Defined Chunking (CDC) तकनीक का उपयोग करता है, जिससे पारंपरिक rsync की तुलना में अधिकतम 30 गुना तेज़ गति मिलती है
  • यह दो मुख्य टूल प्रदान करता है: cdc_rsync और cdc_stream, जो क्रमशः फ़ाइल सिंक्रोनाइज़ेशन और real-time स्ट्रीमिंग का काम करते हैं
  • इसे Windows-आधारित डेवलपर्स को Linux वातावरण में कुशलतापूर्वक फ़ाइलें deploy और test करने के लिए डिज़ाइन किया गया है, इसलिए यह remote development और game development environments में विशेष रूप से उपयोगी है
  • यह ssh और sftp आधारित authentication को सपोर्ट करता है, उपयोग में सहज है, और विभिन्न प्लेटफ़ॉर्म के लिए binaries उपलब्ध कराता है

अवलोकन और प्रोजेक्ट का महत्व

  • CDC File Transfer Google द्वारा open source के रूप में जारी किया गया फ़ाइल ट्रांसफ़र टूल्स का एक सेट है, जो Windows से Linux या Windows के बीच फ़ाइल सिंक्रोनाइज़ेशन और स्ट्रीमिंग को तेज़ और कुशल तरीके से संभालता है
  • यह प्रोजेक्ट Stadia game development environment के लिए बनाया गया था, और मौजूदा scp या rsync की सीमाओं (धीमा ट्रांसफ़र, पूरी फ़ाइल कॉपी, delta mode की कमी) को हल करने के लिए अस्तित्व में आया
  • इसकी मुख्य तकनीक FastCDC नामक Content Defined Chunking algorithm है, जो फ़ाइल बदलने पर केवल वास्तव में बदला हुआ डेटा भेजती है, इसलिए बड़े पैमाने के बार-बार होने वाले सिंक्रोनाइज़ेशन के लिए यह उपयुक्त है
  • open source होने के बावजूद यह commercial-grade performance देता है (उदाहरण: 1500 MB/s सिंक गति, sshfs की तुलना में 2~5 गुना तेज़ स्ट्रीमिंग), और cloud/remote development environments में competing services की तुलना में स्पष्ट रूप से अधिक कुशल है

मुख्य टूल्स का विवरण

cdc_rsync

  • यह Windows से Linux में फ़ाइल सिंक्रोनाइज़ करने का टूल है, और पारंपरिक Linux rsync की कमियों को दूर करता है
  • जिन फ़ाइलों का समय और आकार मेल खाते हैं उन्हें तुरंत skip करता है, और केवल बदली हुई फ़ाइलों को कुशलतापूर्वक ट्रांसफ़र करता है
  • FastCDC का उपयोग करके यह केवल बदले हुए डेटा की स्थिति पहचानकर उसे ट्रांसफ़र करता है, जिससे न्यूनतम ट्रैफ़िक और तेज़ ट्रांसफ़र मिलता है
  • सिंक्रोनाइज़ेशन परीक्षणों में इसने Cygwin पर चलने वाले rsync की तुलना में लगभग 3 गुना, और मानक Linux rsync से भी कहीं बेहतर प्रदर्शन दिखाया
  • यह high-speed compression को सपोर्ट करता है और फ़ाइलों को byte स्तर तक verify करने वाली सरल लेकिन कुशल algorithm संरचना रखता है

cdc_stream

  • यह Windows के folders और files को Linux में मानो local files की तरह real-time स्ट्रीम करके सुलभ बनाता है
  • इसका ढाँचा पारंपरिक sshfs जैसा है, लेकिन फ़ाइल read speed और cache performance को optimize किया गया है
  • change detection और differential streaming के माध्यम से यह केवल बदला हुआ डेटा दोबारा भेजता है, और metadata processing भी तेज़ है
  • Linux directories को readonly रूप में उपलब्ध कराया जाता है, और Windows में बदली गई फ़ाइलें लगभग तुरंत (अधिकतम कुछ सेकंड में) Linux पर दिखाई देती हैं
  • game data जैसी बड़ी फ़ाइलों तक पहुँच की ज़रूरत वाले development environments में इसने वास्तव में sshfs की तुलना में 2~5 गुना performance improvement दिखाया

समर्थित प्लेटफ़ॉर्म

  • cdc_rsync: मुख्य रूप से Windows x86_64 ↔ Ubuntu 22.04 x86_64 के बीच सपोर्ट, remote synchronization और local synchronization दोनों के लिए क्रमिक समर्थन
  • cdc_stream: Windows x86_64 से Ubuntu 22.04 x86_64 तक स्ट्रीमिंग सपोर्ट; विपरीत दिशा या अन्य प्लेटफ़ॉर्म समर्थित नहीं हैं

authentication/सेटअप का तरीका

  • ssh.exe और sftp.exe के माध्यम से passwordless authentication (key-based authentication की सिफारिश)
  • Windows में command-line path या environment variables के माध्यम से commands के विस्तृत path निर्दिष्ट किए जा सकते हैं
  • अतिरिक्त SSH command options और user-specific config file (%USERPROFILE%\.ssh\config) का उपयोग किया जा सकता है
  • Google के internal users के लिए अलग security key आधारित authentication environment variables उपलब्ध हैं

उपयोग के उदाहरण

cdc_rsync उपयोग उदाहरण

  • फ़ाइल सिंक्रोनाइज़ेशन: cdc_rsync C:\path\to\file.txt user@linux.device.com:~
  • wildcard और पूरी directory की recursive synchronization का समर्थन: cdc_rsync C:\path\to\assets\* user@linux.device.com:~/assets -r
  • synchronization status को real time में देखना (-v option), local files के बीच synchronization भी संभव

cdc_stream उपयोग उदाहरण

  • directory streaming शुरू करना: cdc_stream start C:\path\to\assets user@linux.device.com:~/assets
  • streaming session रोकना: cdc_stream stop user@linux.device.com:~/assets
  • wildcard के साथ कई sessions प्रबंधित किए जा सकते हैं

समस्या समाधान और logging

  • cdc_stream background service आधारित चलता है, और logs डिफ़ॉल्ट रूप से %APPDATA%\cdc-file-transfer\logs path में सहेजे जाते हैं
  • विस्तृत logs और debugging options उपलब्ध हैं (verbosity level JSON settings)
  • cdc_rsync console logs आउटपुट करता है, और -vvv, -vvvv के साथ अधिक विस्तृत logs देखे जा सकते हैं
  • असफल SSH/SFTP commands को trace करके उन्हें सीधे चलाकर समस्या के कारण का विश्लेषण करना आसान है

तकनीकी स्टैक और संचालन संबंधी जानकारी

  • मुख्य development language C++ है, और कुछ Python/बिल्ड प्रबंधन के लिए Starlark का उपयोग हुआ है
  • Apache-2.0 लाइसेंस, 8 से अधिक contributors, और GitHub पर 3.3k stars
  • 2023 के बाद से अतिरिक्त development के बिना Archived स्थिति में है

सारांश

  • CDC File Transfer Windows-Linux के बीच बड़े फ़ाइलों और directories के बार-बार ट्रांसफ़र में उद्योग-स्तरीय शीर्ष दक्षता और गति प्रदान करता है
  • remote development, gaming, media, data analysis जैसे cross-platform environments में यह synchronization और streaming प्रक्रियाओं को काफी छोटा कर देता है
  • अन्य synchronization/streaming tools की तुलना में सरलता, तेज़ partial change detection, और उत्कृष्ट cache capabilities इसकी मज़बूत प्रतिस्पर्धात्मकता बनाते हैं
  • SSH/SFTP authentication और command-line या config file आधारित लचीली सेटिंग्स के कारण engineers इसे आसानी से अपना और संचालित कर सकते हैं
  • source code देखा और customize किया जा सकता है, और open source community में यह पहले से ही उच्च प्रतिष्ठा और उपयोगिता दर्ज कर चुका है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-02
Hacker News राय

  • पिछले साल से Content Defined Chunking पर तरह-तरह के प्रयोग कर रहा हूँ (खासकर bonanza.build)। पता चला कि सबसे व्यापक रूप से इस्तेमाल होने वाले FastCDC algorithm में भी सुधार की गुंजाइश है, और lookahead approach इस्तेमाल करने पर performance काफी बेहतर हो जाती है। इसके implementation के लिए buildbarn/go-cdc देखें

    • यह lookahead तरीका Lempel-Ziv compressor में “lazy matching” से काफी मिलता-जुलता लगता है (संबंधित ब्लॉग)। Buzhash के साथ तुलना के नतीजे जानने की उत्सुकता है। आम तौर पर gearhash की संरचना सरल होने के कारण उसके तेज़ होने की उम्मीद रहती है। वैसे gear init के लिए mt19937 की जगह rand/v2 का seeded generator ज़्यादा उपयुक्त हो सकता है
    • bonanza.build काफी प्रभावशाली है। अगर मैं अब भी Bazel इस्तेमाल कर रहा होता, तो इसे ज़रूर आज़माता
    • सोच रहा हूँ कि अगर go-cdc को fastcdc की जगह cdc_rsync में इस्तेमाल किया जाए, तो performance में कितना फ़र्क पड़ेगा
    • यह भी सोचने पर मजबूर करता है कि क्या AI इस क्षेत्र में योगदान दे सकता है। data compression (AI-आधारित compression उदाहरण), RF modulation optimization (पेपर लिंक) जैसी जगहों पर AI पहले से उपयोगी साबित हो रहा है। उम्मीद है कि छोटे models, खासकर SSM family, को chunk boundary optimization सीखाने के लिए इस्तेमाल किया जा सकता है

  • क्या rsync पहले से ही content-defined chunk boundaries को rolling hash condition से define करके इस्तेमाल नहीं करता? (विकी लिंक1, विकी लिंक2)। rsync की तुलना में speedup शायद rolling hash की efficiency और native Windows executable के इस्तेमाल (Windows file system धीमा है) जैसी वजहों से हो सकता है। फिर भी performance improvement दिलचस्प है, और इसका open source होना भी सकारात्मक है। अच्छा होगा अगर यह तरीका rsync के अंदर भी आ जाए

    • rsync content-defined chunking का उपयोग नहीं करता, बल्कि destination file पर fixed-size blocks का उपयोग करता है। rolling hash की मदद से source file में कहीं भी उन blocks को पहचाना जा सकता है ताकि दोबारा transfer करने से बचा जा सके (तकनीकी दस्तावेज़)
    • repo का README rsync के approach से इसके अंतर को बहुत ही अच्छे ढंग से समझाता है
    • rsync अब लगभग ठहरा हुआ project लगता है। लंबे समय से maintain ज़रूर हो रहा है, लेकिन कई quality improvements छूट गए हैं, और अब यह कुछ-कुछ vim जैसा लगता है—सिद्धांततः maintained, पर व्यवहार में विकास लगभग नहीं के बराबर

  • अच्छा लगा कि Stadia ने इस तरह एक और दीर्घकालिक लाभ छोड़ दिया। अफ़सोस है कि self-hosted version नहीं आया; आज के DRM वाले दौर में अगर आता भी, तो शायद तुरंत piracy जैसा मान लिया जाता

    • self-hosted game streaming के लिए moonlight और sunshine का combination recommend किया जाता है। यह बहुत अच्छी तरह काम करता है
    • मैंने सुना था कि Stadia में direct self-hosting संभव नहीं था। developers को Stadia support के लिए अलग build बनाना पड़ता था, और शायद यह एक अलग DirectX replacement platform था। यह Proton जैसे हल्के emulation environment जैसा भी हो सकता था, लेकिन जिन games को मैंने वास्तव में खेला, उनमें game के अंदर Stadia-specific custom key bindings (Stadia-only symbols) दिखते थे। यानी साफ़ तौर पर customization था। यह तरीका PlayStation, Xbox और Nvidia की game streaming से भी स्पष्ट रूप से अलग था। Amazon Luna के बारे में पक्का नहीं कह सकता
    • self-hosted remote game streaming के लिए Moonlight/Sunshine(Apollo) देखें। Stadia के लिए अलग dedicated build चाहिए होता है, इसलिए इसका महत्व सीमित है
    • DRM के दौर में ‘piracy’ से ठीक-ठीक क्या मतलब है, यह जानने की जिज्ञासा है। क्या इसका मतलब अपनी ही खरीदी हुई PC game को cloud के ज़रिए stream करना है?
    • “self-hosting Stadia” जैसी चीज़ें असल में पहले से कई services और tools में लागू हो चुकी हैं। Steam में खुद शानदार game streaming built-in है। Nvidia और AMD ने भी पहले GPU drivers में यह सुविधा दी थी, और Steam Deck पर भी games stream किए जा सकते हैं। Sony के PS4/PC streaming और Microsoft के Xbox streaming जैसे भी कई उदाहरण हैं

  • जिन्हें यह जानना था कि Content Defined Chunking वास्तव में chunk कैसे बनाता है, उनके लिए यह ब्लॉग और यह ब्लॉग दोनों concepts को बहुत आसान तरीके से समझाते हैं

    • धन्यवाद। मूल लिंक में विस्तार से समझाया नहीं गया था, इसलिए थोड़ी निराशा हुई थी; अब इन्हें जल्द पढ़ने का इरादा है

  • मुख्य पंक्ति: "यह remote diffing algorithm CDC(Content Defined Chunking) पर आधारित है, और tests में rsync से अधिकतम 30 गुना तेज़ है (1500MB/s बनाम 50MB/s)"

  • क्या किसी को पता है कि इस feature को standard rsync tool में integrate करने का कोई काम चल रहा है? अच्छा होगा अगर यह व्यापक रूप से इस्तेमाल हो, लेकिन official website देखने पर लगता है कि Linux-to-Linux के बीच तो इसका support ही नहीं है, जो थोड़ा खटकता है

    • Linux-to-Linux support और अधिक सामान्य compatibility पर चर्चा यहाँ 1 और यहाँ 2 में संकलित है

  • यह project भी काफ़ी शानदार लगा। मैंने अपने काम के लिए इसी तरह की functionality खुद implement की थी, और कठिन constraints वाले मामलों में यह काफ़ी महत्वपूर्ण हो सकता है। फिर भी यह विचार आता है कि rsync से शुरू करना शायद आसान होता

    • इसमें कहा गया है कि “scp केवल पूरी files कॉपी करता है, delta mode नहीं है, और बहुत सी छोटी files होने पर धीमा पड़ता है, साथ ही compression भी धीमा है”, लेकिन rsync में -z option के ज़रिए compression इस्तेमाल किया जा सकता है (विवरण)। अगर CPU पर्याप्त हो, तो -z option recommend किया जाता है और speed भी बढ़ती है। बहुत तेज़ न सही, पर मुझे लगता है कि scp की तुलना में rsync बेहतर शुरुआती बिंदु है
    • “remote diffing algorithm CDC पर आधारित है, और tests में rsync से अधिकतम 30 गुना तेज़ है (1500 MB/s vs 50 MB/s)”
    • rsync कुछ क्षेत्रों, खासकर game development में, पर्याप्त रूप से optimized नहीं लगता। game development में अक्सर दसियों लाख files और directories कॉपी करनी पड़ती हैं, लेकिन rsync directories/files के creation को serialize करने की प्रवृत्ति के कारण बहुत धीमा हो जाता है। मैंने GNU parallel आदि के साथ इसे N rsync jobs में बाँटकर चलाया, या खुद file lists बनाकर भी देखा, लेकिन आख़िरकार syncthing जैसे pre-indexing समर्थ tools से समस्या हल हुई

  • सोच रहा हूँ कि क्या यह तकनीक git पर भी लागू हो सकती है। git blob hash बनाते समय length information शामिल करता है, इसलिए data का केवल एक हिस्सा बदलने पर भी शुरू से hash दोबारा calculate करना पड़ता है। CDC के साथ यह कहीं अधिक efficient लग सकता है

    • git lfs को replace करने के लिए xet में CDC approach वास्तव में लागू की गई है (संबंधित उदाहरण)
    • restic/borg जैसे backup tools भी CDC का उपयोग करते हैं, लेकिन git replacement के रूप में अभी तक कोई ठोस प्रयास हुआ है या नहीं, यह जानना चाहूँगा

  • यह विवरण प्रभावशाली लगा: “latest release के precompiled binaries को Windows पर download करके unzip कर लें। Linux binary अपने-आप Windows tool से ~/.cache/cdc-file-transfer में deploy हो जाएगी। अलग installation की ज़रूरत नहीं है।” rsync के विपरीत, Linux destination पर अलग service install किए बिना इसका काम करना अच्छा लगा। rsync की यह बात थोड़ी असुविधाजनक लगती थी

    • वास्तव में rsync का सबसे आम उपयोग यह है कि वह ssh के ज़रिए remote side पर receiving process को अपने-आप चला देता है। cdc भी उसी तरह काम करता है, इसलिए यह कहना कि rsync इस्तेमाल करने के लिए अलग service installation चाहिए, एक गलतफ़हमी है

  • क्या IBM Aspera भी इसी तरह काम करता है, यह जानने की जिज्ञासा है। जब मैं game publisher QA में काम करता था, तब Aspera से screen recordings upload करता था, और यह office internet की सामान्य upload speed से कहीं तेज़ दिखता था (IBM Aspera परिचय)