You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/en/experimental-features/PDPCURIOSPEC.md
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,6 @@ TODO: the pdp datasets table etc
20
20
## Managing Pieces
21
21
TODO: add, upload, delete, pull, info
22
22
TODO: the pdp pieceref table etc
23
-
TODO: "finalization" notify task
24
23
25
24
# Storage
26
25
@@ -179,13 +178,18 @@ The sections below describe how tasks and watchers connect to form the PDP lifec
179
178
180
179
## Piece Ingestion
181
180
182
-
There are two paths for getting pieces into the system:
181
+
There are three paths for getting pieces into the system:
183
182
184
183
**Known-CID direct upload path:**
185
184
1. The client posts the PieceCID. If a complete long-term copy already exists, the handler creates its `parked_piece_refs` and `pdp_piecerefs` rows immediately.
186
185
2. Otherwise, the client PUTs the bytes to the returned upload URL. The handler claims a `parked_pieces` row, writes the request body once directly to final piece storage while computing CommP, and validates the declared size and PieceCID.
187
186
3. After the write succeeds, one database transaction marks the parked piece complete, creates `pdp_piecerefs`, and deletes the upload row. The legacy `notify` request field is accepted for compatibility but this path does not call the URL or schedule a notify task.
188
187
188
+
**Streaming upload path:**
189
+
1. The client creates an upload session and PUTs bytes without declaring a PieceCID. The handler claims a provisional `parked_pieces` identity for that session, then streams the request once directly into final piece storage while calculating CommP and the raw size.
190
+
2. After the PieceCID is known, one transaction promotes the provisional row to the calculated identity. If a matching complete piece already exists, the session is pointed at that piece and the unreferenced provisional copy is left for normal parked-piece cleanup.
191
+
3. The client finalizes with the calculated PieceCID. The handler validates it, creates `pdp_piecerefs`, and deletes the streaming session in one transaction. It does not use scratch space, create an intermediate `pdp_piece_uploads` row, or schedule a notify task.
192
+
189
193
**Pull path:**
190
194
1. Client submits a pull request via HTTP, creating a row in `pdp_piece_pull_items`.
191
195
2.**PDPv0_PullPiece** downloads the piece from the external URL, computes and verifies CommP, and stores the result in `parked_pieces` + `pdp_piecerefs`.
0 commit comments