ハクソク

世界を動かす技術を、日本語で。

CDCファイル転送

237日前原文(github.com)

概要

  • CDC File Transfer は、Stadia終了後に開発されたファイル同期・ストリーミングツール群
  • FastCDC アルゴリズムを用いた差分転送で高速化・効率化を実現
  • WindowsからLinuxへの大容量・多数ファイルの転送に特化
  • cdc_rsync と cdc_stream の2つの主要ツールを提供
  • SSH/SFTPを利用した簡単なセットアップと運用

CDC File Transferとは

  • Stadia サービス終了後に生まれた、WindowsとLinux間のファイル同期・配信ツール群
  • Content Defined Chunking (CDC)、特に FastCDC を利用したファイル分割・差分検出
  • ゲーム開発現場での大容量ファイル転送・反復作業の効率化を目的
  • 従来の scp や rsync の課題（全転送、遅い圧縮、小ファイル多数での低速化）を解決
  • cdc_rsync と cdc_stream の2ツールで柔軟な運用

cdc_rsyncの特徴

  • WindowsからLinux へのファイル同期専用ツール
  • 既存ファイルの タイムスタンプ・サイズ を比較し、差分のみ転送
  • 高速圧縮 を標準搭載
  • CDCアルゴリズム によるリモート差分検出で大幅な高速化（最大30倍速）
  • 固定サイズではなく、 可変サイズチャンク で転送範囲を最小化
  • rsync のような複雑なハッシュマップ探索を不要化
  • 検証結果：大規模ビルド（40-45GB）で 3倍以上の高速化 を実現

技術的な優位点

  • 固定チャンク ではなく 可変チャンク 採用により、途中挿入・削除時も差分範囲を限定
  • チャンク境界の計算が 高速・簡易 （左シフト、メモリ参照、加算、AND演算のみ）
  • 差分検出が 集合演算 で完結し、1バイトごとの探索を排除

cdc_streamの特徴

  • WindowsからLinux へのファイル・ディレクトリのストリーミング転送ツール
  • sshfs に近いが、 読込速度特化 とキャッシュ機構を実装
  • Linux側でファイル再読込時も 差分のみ再転送、残りはキャッシュから取得
  • ディレクトリ情報も 高速ストリーミング 対応
  • CDCベースの差分検出 をcdc_rsyncと共通利用
  • Windows更新内容の即時反映 （0.5秒+変更ファイル合計GB数×0.7秒の遅延）
  • 書き戻し不可 （Linux側はReadOnly）
  • ゲーム起動～メニュー到達までの時間で 2～5倍の高速化 を確認

サポートプラットフォーム

  • cdc_rsync
    • Windows x86_64：送信・受信対応
    • Ubuntu 22.04 x86_64：受信のみ対応
    • Ubuntu aarch64, macOS：非対応
  • cdc_stream
    • Windows x86_64：送信のみ対応
    • Ubuntu 22.04 x86_64：受信のみ対応
    • その他：非対応
    • ※詳細・制限事項はIssue参照

インストール・ビルド手順

  • Windows用バイナリ はリリースからダウンロード・解凍
  • Linuxバイナリ はWindowsツールが自動配置（~/.cache/cdc-file-transfer）
  • ソースビルド も可能（Bazel, Git, SSH/SFTPクライアントが必要）

ビルド手順（抜粋）

  • Bazelインストール
  • リポジトリクローン＋サブモジュール初期化
  • 必要なターゲットを各OSでビルド
  • Linux側バイナリをWindowsにコピー

SSH・SFTP設定

  • パスワード不要のSSH/SFTP 接続設定（公開鍵認証推奨）
  • Windowsコマンドプロンプトでssh/sftpコマンドが無入力で通ることを確認
  • SSH configファイル や 環境変数 で詳細パラメータ指定可能
  • Google内部利用時は Googleセキュリティキー 対応コマンド指定も可能

各ツールの使い方

  • cdc_rsync

    • 単一ファイル転送：cdc_rsync C:\path\to\file.txt user@linux.device.com:~
    • ワイルドカード対応：cdc_rsync C:\path\to\*.txt user@linux.device.com:~
    • ディレクトリ再帰転送：cdc_rsync C:\path\to\assets\* user@linux.device.com:~/assets -r
    • 進捗表示：-vオプション追加
    • ローカル間同期も可能

  • cdc_stream

    • ディレクトリストリーミング開始：cdc_stream start C:\path\to\assets user@linux.device.com:~/assets
    • ストリーミング停止：cdc_stream stop user@linux.device.com:~/assets
    • ワイルドカードで複数セッション停止も可能

トラブルシューティング・ログ

  • 初回起動時、cdc_streamは バックグラウンドサービス を起動
  • ログは%APPDATA%\cdc-file-transfer\logsに出力
  • サービス用JSON設定ファイル（例：{"verbosity":3}）で詳細ログやカスタム引数指定可能

まとめ

  • CDC File Transfer は、Windows・Linux間での大容量・高頻度なファイル同期・ストリーミングを大幅に効率化
  • cdc_rsync ：差分転送・高速化・シンプルな運用
  • cdc_stream ：即時ストリーミング・キャッシュ・高速読込
  • SSH/SFTP環境 さえ整えれば、導入・運用も容易
  • ゲーム開発など 反復作業の多い現場 で特に有効

Hackerたちの意見

Stadiaが長期的に何か役立ったのを見るのは嬉しいね。でも、自己ホスティング版を作らないのは残念だな。今のDRMの世界じゃ、それをやるとただの海賊行為になっちゃうし。

└

今のDRMの世界ではただの海賊行為だよね…それが今まで以上に重要で必要なんだ。音楽を聞きたいって聞かれたら、SpotifyじゃなくてBitTorrentから取るように勧めてるよ。

└

DRMの世界での海賊行為ってどういう意味？自分のPCゲームをクラウドで共有できるってこと？

└

自己ホスティングのゲームストリーミングにはMoonlightとSunshineを使うといいよ。私の経験ではすごくうまくいった。

└

おそらく実現可能ではなかったと思う。開発者たちはゲームをStadia対応でコンパイルしなければならなかったと聞いたから。もしかしたら、全く別のプラットフォームで、独自のDirectXの代替があったのかもしれないし、軽量エミュレーション（Protonみたいな）を使っていたのかもしれない。確か、私がプレイした数少ないゲームでは、カスタムのStadiaキー設定（Stadiaのシンボル付き）があったような気がする。ゲーム内ではそんな風に表示されてたから、確かにカスタマイズはあったね。これはPlayStationやXbox、さらにはNvidiaが採用しているモデルとは違うよね。Amazon Lunaについては知らないけど。

└

残念ながら、Stadiaはそういう風に設計されていたから、これは不可能なんだよね。ところで、1年後にはすでに「陳腐化」するカスタムハードウェアを使うアイデアを考えたのは誰なんだろう？互換レイヤーの代わりにLinuxネイティブを使うことを考えた人は誰？元のStadiaのウェブサイトには検索バーすらなかったのはどうして？

└

ゲームの自己ホスト型リモートストリーミングにはMoonlight / Sunshine（Apollo）を見てみて。Stadiaは特別なバージョンのゲームが必要だったから、あまり役に立たないかも。

Steamはゲームのアップデートにこういうことをやってるの？

└

残念ながら、Steamはこういうローリングハッシュ（fastcdcやbuzhashなど）を使ってないんだ。ファイルを1MBのチャンクに分けて、それをハッシュ化して、その粒度で更新してるよ。 https://partner.steamgames.com/doc/sdk/uploading#AppStructur...

cdc_rsyncは、WindowsマシンからLinuxデバイスにファイルを同期するツールで、標準のLinux rsyncに似てる。これってLinuxからLinuxにも使えるの？

└

使えないよ: https://github.com/google/cdc-file-transfer?tab=readme-ov-fi...

昨年からContent Defined Chunkingの実験をたくさんやってるんだ（https://bonanza.build/のために）。発見したことの一つは、最も一般的に使われているアルゴリズムFastCDC（このプロジェクトでも使われてるやつ）が、先読みをすることで大幅に改善できるってこと。実装はここにあるよ： https://github.com/buildbarn/go-cdc

└

この先読みはLempel-Ziv圧縮器で使われる「レイジーマッチング」にすごく似てるね！ https://fastcompression.blogspot.com/2010/12/parsing-level-1... Buzhashと比べた？ gearhashの方が、よりシンプルなイテレーション構造だから速いと思うけど。（それに、rand/v2のシード生成器はmt19937よりgear初期化に向いてるかも）

└

go-cdcを使うことによるcdc_rsyncのパフォーマンスへの影響はどのくらいだと思う？

誰か、これを標準のrsyncツールに統合する作業が進められているか知ってる人いる？（オプション機能としてでも）これは非常に便利な改善だと思うから、広く利用可能であるべきだよね。このウェブサイトから見ると、LinuxからLinuxへの転送にも対応していないのはちょっと残念だね。

└

LinuxからLinuxへの互換性がうまくいかないことや、もっと広い互換性についての考えは、ここで見つけられるよ。[1]と[2]をチェックしてみて。

これがgitに適用できるか気になるな。gitのblobは10進数の長さのヘッダーでハッシュ化されていて、少しでも内容を変更すると、最初からハッシュを計算し直さなきゃいけないんだ。CDCみたいなものがあれば、これが大幅に改善されると思う。

└

xetではgit lfsの代わりにこれが使われてるよ： https://huggingface.co/blog/from-files-to-chunks

└

resticやborgみたいなバックアップツールがこれをやってるけど、誰かがgitの代わりに使ったことあるのかな。

  • https://github.com/google/cdc-file-transfer/issues/56#issuec...
  • https://github.com/librsync/librsync/issues/242

重要な文: 「リモートの差分アルゴリズムはCDC（Content Defined Chunking）に基づいています。私たちのテストでは、rsyncで使われているものより最大30倍速い（1500 MB/s対50 MB/s）です。」

ちょっと混乱してるんだけど、rsyncってすでにコンテンツに基づいたチャンク境界を使ってるんじゃないの？ローリングハッシュで境界を定義する条件があるよね？ https://en.wikipedia.org/wiki/Rolling_hash#Content-based_sli... https://en.wikipedia.org/wiki/Rolling_hash#Content-based_sli... rsyncに対する速度向上は、より効率的なローリングハッシュアルゴリズムに関連してるみたいだし、もしかしたらcygwinの代わりにネイティブのWindows実行ファイルを使ってるからかも（Windowsのファイルシステムは遅いことで有名だから、そこが影響してるかも）。それとも何か見落としてる？とにかく、パフォーマンス向上は興味深いね。ソースがオープンになったのは嬉しいし、rsyncに取り入れられることを願ってる。

└

rsyncって、なんか時が止まってる感じだよね。ずっと前からあって、基本的な小さな改善がたくさんできるはずなのに、全然されてない。今のvimみたいに、理論上だけはメンテナンスされてるって感じ。

└

Rsyncは固定サイズのチャンクを使ってるんだよね。だから、その境界からバイトを挿入したり削除したりすると、後のチャンクのハッシュが合わなくなっちゃう。だけど、このプロジェクトでは可変サイズのチャンクを使ってるんだ。挿入や削除があっても、影響を受けるのはそのローカルチャンクだけで、後のチャンクはそのままだからスキップできるんだよ。