← Commit history

docs(web-control): chunk size is TRANSPORT-dependent - ~1 MB over HTTP but <=16 KB over the CLI, where the payload rides in argv and Windows caps the command line at 32,767 chars (24 KB fails with WinError 206 before ab is reached)

John Lauer ·efc69c4fdb ·2mo ago ·parent 1fa7c6b
1 file changed +16−3
docs/web-control.md+16−3
@@ -138,9 +138,22 @@ write_file_chunk {path, dataB64, offset, final?, sha256?, createDirs?}   -> {path, offset, bytesWritten, size, nextOffset, final, sha256?, verified?} ``` -Loop: send ~1 MB of **raw** bytes per call, advance to the returned `nextOffset`, set-`final:true` on the last chunk. Pass the source `sha256` on that final chunk and ab hashes the-reassembly and verifies it for you.+Loop: advance to the returned `nextOffset` each call and set `final:true` on the last chunk.+Pass the source `sha256` on that final chunk and ab hashes the reassembly and verifies it for you.++**Chunk size depends on your transport**, because base64 inflates ~33%. Measured, not assumed:++| caller | chunk of RAW bytes | why |+|---|---|---|+| a web page / the direct API (HTTP) | **~1 MB** | body cap ~2.5 MB |+| the `adom-bridge` CLI on Windows | **16 KB or less** | the payload rides in ARGV, and Windows caps a command line at 32,767 chars |+| a container shipping a big file | use `send_files` | streams over the relay, no such limit |++The CLI ceiling is sharp and it fails *before ab is reached*: 16 KB raw (~22,000 argv chars)+succeeds and verifies; 24 KB (~32,987 chars) does not spawn at all, returning `WinError 206`.+Credit to the fusion-bridge thread for the general warning - they hit the same class from the+container side with a 245 KB STEP failing `errno 7` (E2BIG) in argv, which is what prompted+measuring this properly.  Three properties worth relying on: