付録: 最小限のデータ構造 (マニフェスト/チャンク/状態)

この付録では、「並列チャンク + 再開可能な転送 + 冪等な再試行」に関する最小限のデータ構造の推奨事項を提供します。目標は、複雑なトランザクションを使用せずに、高スループットの同時実行と障害後の信頼性の高いリカバリを可能にすることです。

一般原則

大きなオブジェクトと小さな状態: チャンク/マニフェストは、オブジェクトストレージに保存される大きなオブジェクトです。状態は小さく、状態ストアに格納されます。
一意のキーとべき等性: 冪等な再送信のために、チャンクは (transferId、fileId、chunkIndex) によって一意にアドレス指定可能でなければなりません (MUST)。
Recoverability: リカバリが完了した部分をスキップできるように、状態は「完了したセット」を表現しなければなりません。
敏感な漏れはありません: オブジェクトのキーと状態には、電子メールや元のファイル名などの機密フィールドを埋め込むことは避けるべきです (これらが暗号化されるかどうかはプライバシーポリシーによって異なります)。

マニフェストは、ダウンロードと再構築のための受信者の「単一のエントリポイント」です。最小限の推奨事項:

manifestVersion：必ず。互換性のアップグレードに使用されます (例: 1).
transferId：必ず。一意の転送セッション識別子。
作成日 / 期限切れ: すべきです。ライフサイクル処理と UI ヒント用。
policy: すべきです。ポリシーの概要 (ダウンロード数の制限、パスワードの要件、完了前の共有が許可されているかどうかなど)。
ファイル[]：必ず。ファイルリストの説明 (最小ファイルサイズとチャンク範囲)。
chunking：必ず。 chunkSize と chunkCount の計算方法、またはファイルごとの chunkCount が含まれます。
objectKeyRule：必ず。 (transferId、fileId、chunkIndex) からオブジェクトキーを取得するか、明示的なマッピングテーブルを提供します。

固有のアドレス指定: チャンクは (transferId、fileId、chunkIndex) によって一意にアドレス指定可能でなければなりません。
冪等アップロード: 同じチャンクを再アップロードする場合、最終状態を壊してはなりません (上書きまたは拒否される可能性がありますが、動作は一貫していなければなりません)。
最小限のメタデータ: サーバーは、可観測性とトラブルシューティングのために、暗号文の長さ、書き込み時間、etag/バージョンなどのみを記録してもよい(MAY)。

制約: オブジェクトキーは、次による一括クリーンアップをサポートしなければなりません。 transferId 接頭語;オブジェクトキーは機密性の高いビジネス情報を持ち込まないようにする必要があります (SHOULD)。

州は「アップロード/ダウンロードの進行状況と回復」と回答します。小さくて読み取り/書き込みが速い必要があります。

transferId：必ず。
status：必ず。推奨される値: UPLOADING / READY / DELETED / EXPIRED.
uploadedSet：必ず。完成したチャンクセット。ビットマップ/範囲セットを使用して圧縮する必要があります。
uploadedBytes: すべきです。進行状況の表示とクォータチェック用 (チャンクから派生できますが、それを維持する方が高速です)。
downloadCount：5月。ダウンロード数制限を強制する場合は、それを記録し、アトミックに更新する必要があります (詳細はストレージによって異なります)。
expiresAt: すべきです。有効期限の強制とバックグラウンドのクリーンアップ用。

再開可能な転送の場合、サーバーは以下を返せる必要があります: