alex/copyparty
1
0
Fork 0
mirror of https://github.com/9001/copyparty.git synced 2026-01-04 18:45:38 +10:00
Code Issues Packages Projects Releases Wiki Activity

explain tus incompatibility + update docs

Browse Source
This commit is contained in:
ed
2023-04-19 21:46:33 +00:00
parent dbbba9625b
commit 418000aee3
2 changed files with 14 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/devnotes.md
View File

@@ -4,6 +4,7 @@
* [future plans](#future-plans) - some improvement ideas
* [design](#design)
* [up2k](#up2k) - quick outline of the up2k protocol
* [why not tus](#why-not-tus) - I didn't know about [tus](https://tus.io/)
* [why chunk-hashes](#why-chunk-hashes) - a single sha512 would be better, right?
* [http api](#http-api)
* [read](#read)
@@ -66,6 +67,13 @@ regarding the frequent server log message during uploads;
* on this http connection, `2.77 GiB` transferred, `102.9 MiB/s` average, `948` chunks handled
* client says `4` uploads OK, `0` failed, `3` busy, `1` queued, `10042 MiB` total size, `7198 MiB` and `00:01:09` left
## why not tus
I didn't know about [tus](https://tus.io/) when I made this, but:
* up2k has the advantage that it supports parallel uploading of non-contiguous chunks straight into the final file -- [tus does a merge at the end](https://tus.io/protocols/resumable-upload.html#concatenation) which is slow and taxing on the server HDD / filesystem (unless i'm misunderstanding)
* up2k has the slight disadvantage of requiring the client to hash the entire file before an upload can begin, but this has the benefit of immediately skipping duplicate files
* and the hashing happens in a separate thread anyways so it's usually not a bottleneck
## why chunk-hashes
a single sha512 would be better, right?