Logo

Anhang: Minimale Datenstrukturen (Manifest/Chunk/State)

Dieser Anhang enthält minimale Datenstrukturempfehlungen für „paralleles Chunking + wiederaufnehmbare Übertragung + idempotente Wiederholungsversuche“. Ziel ist es, Parallelität mit hohem Durchsatz und zuverlässige Wiederherstellung nach Ausfällen zu ermöglichen – ohne komplexe Transaktionen.

Allgemeine Grundsätze

  • Große Objekte vs. kleiner Staat: Chunks/Manifest sind große Objekte, die im Objektspeicher gespeichert sind. Der Zustand ist klein und wird in einem Zustandsspeicher gespeichert.
  • Eindeutige Schlüssel und Idempotenz: Ein Chunk MUSS durch (transferId, fileId, chunkIndex) für idempotente Neuübertragungen eindeutig adressierbar sein.
  • Recoverability: Der Zustand MUSS den „abgeschlossenen Satz“ ausdrücken, damit bei der Wiederherstellung abgeschlossene Teile übersprungen werden können.
  • Keine empfindliche Leckage: Objektschlüssel und -status SOLLTEN die Einbettung sensibler Felder wie E-Mail oder Originaldateinamen vermeiden (ob diese verschlüsselt sind, hängt von Ihrer Datenschutzrichtlinie ab).

A.1 Manifestieren Sie minimale Felder

Das Manifest ist der „einzige Einstiegspunkt“ des Empfängers zum Herunterladen und erneuten Zusammenstellen. Minimale Empfehlungen:

  • manifestVersion: MUSS. Wird für Kompatibilitätsaktualisierungen verwendet (z. B. 1).
  • transferId: MUSS. Eindeutige Übertragungssitzungs-ID.
  • erstellt am / läuft ab: SOLLTE. Für die Handhabung des Lebenszyklus und Hinweise zur Benutzeroberfläche.
  • policy: SOLLTE. Eine Zusammenfassung der Richtlinien (Grenzwerte für die Anzahl der Downloads, Kennwortanforderungen, ob die Freigabe vor dem Abschluss zulässig ist usw.).
  • Dateien[]: MUSS. Beschreibung der Dateiliste (bei minimalen Dateigrößen und Blockbereichen).
  • chunking: MUSS. Beinhaltet chunkSize und wie chunkCount berechnet wird, oder chunkCount pro Datei.
  • objectKeyRule: MUSS. Leiten Sie Objektschlüssel von (transferId, fileId, chunkIndex) ab oder stellen Sie eine explizite Zuordnungstabelle bereit.

A.1.1 Minimale Dateien[]-Felder

  • fileId: MUSS. Eindeutige Dateikennung (verwenden Sie den Dateinamen nicht als eindeutigen Schlüssel).
  • size: MUSS. Größe in Bytes.
  • mime: MAI. Für Anzeige- und Downloadvorschläge.
  • name: MAI. Wenn Sie striktes Wissensfreiheit/minimale Leckage wünschen, lassen Sie es weg name oder einen verschlüsselten Namen speichern.
  • chunkCount: MUSS. Chunk-Anzahl für diese Datei.
  • chunkOffset: MAI. Wenn mehrere Dateien ein globales teilen chunkIndex, ein Offset ist erforderlich; andernfalls kann es weggelassen werden.

A.1.2 Integritäts- und Verifizierungsfelder (optional, aber empfohlen)

  • chunkHashes[]: SOLLTE. Überprüfung pro Chunk (einer oder eine Kombination aus Hash/Länge/Etag).
  • fileHash: MAI. Prüfsumme der gesamten Datei (nach dem Download überprüfen).
  • ciphertextLength: MAI. Längenkonsistenzprüfungen auf Chiffretextebene (kein Klartext erforderlich).

A.2 Chunk-Objekte: minimale Einschränkungen

  • Eindeutige Adressierung: Ein Chunk MUSS durch (transferId, fileId, chunkIndex) eindeutig adressierbar sein.
  • Idempotenter Upload: Das erneute Hochladen desselben Blocks DARF NICHT den Endzustand zerstören (er kann überschrieben oder abgelehnt werden, aber das Verhalten muss konsistent sein).
  • Minimale Metadaten: Der Server KANN zur besseren Beobachtbarkeit und Fehlerbehebung nur die Länge des Chiffretexts, die Schreibzeit, das Etag/die Version usw. aufzeichnen.

A.2.1 Objektschlüsselregel (Beispiel)

  • /transfers/{transferId}/chunks/{fileId}/{chunkIndex}
  • /transfers/{transferId}/manifest

Einschränkung: Objektschlüssel MÜSSEN die Massenbereinigung unterstützen transferId Präfix; Objektschlüssel SOLLTEN vermeiden, dass vertrauliche Geschäftsinformationen übertragen werden.

A.3 Staatliche Aufzeichnungen: minimale Felder

Geben Sie als Antwort „Upload-/Download-Fortschritt und Wiederherstellung“ an. Es sollte klein und schnell zu lesen/schreiben sein.

  • transferId: MUSS .
  • status: MUSS. Empfohlene Werte: UPLOADING / READY / DELETED / EXPIRED.
  • uploadedSet: MUSS. Fertiger Chunk-Satz; SOLLTE mit einem Bitmap-/Bereichssatz komprimiert werden.
  • uploadedBytes: SOLLTE. Zur Fortschrittsanzeige und Quotenprüfung (kann aus Chunks abgeleitet werden, ist aber schneller beizubehalten).
  • downloadCount: MAI. Wenn Sie Download-Anzahlbeschränkungen erzwingen, müssen diese atomar aufgezeichnet und aktualisiert werden (Details hängen von Ihrem Speicher ab).
  • expiresAt: SOLLTE. Zur Durchsetzung des Ablaufs und zur Hintergrundbereinigung.

A.3.1 Minimale Ausgabe für eine Wiederherstellungs-API

Für fortsetzbare Übertragungen SOLLTE der Server Folgendes zurückgeben können:

  • Übertragungsstatus (HOCHGELADEN/BEREIT/GELÖSCHT/ABGELAUFEN)
  • uploadedSet (vollständiger Chunk-Satz)
  • Richtlinienzusammenfassung (z. B. Überschreitung des Kontingents, abgelaufen, ob ein fortgesetzter Upload zulässig ist)

Hinweis: Grenze im Vergleich zum Whitepaper zu Sicherheit und Datenschutz

  • In diesem Anhang werden nur die „Strukturen und Einschränkungen“ beschrieben, die für die Übertragung/Speicherung erforderlich sind.
  • Informationen zu Verschlüsselungsfeldern, zur Übertragung/Ableitung von Schlüsselmaterial und zum Fail-Closing-Verhalten bei Authentifizierungsfehlern finden Sie im Whitepaper zu Sicherheit und Datenschutz.