mirror of
https://github.com/tailscale/tailscale.git
synced 2024-11-25 19:15:34 +00:00
3f27087e9d
While the previous logic was correct, it did not perform well. Resuming is a dance between the client and server, where 1. the client requests hashes for a partial file, 2. the server then computes those hashes, 3. the client computes hashes locally and compares them. 4. goto 1 while the partial file still has data While step 2 is running, the client is sitting idle. While step 3 is running, the server is sitting idle. By streaming over the block hash immediately after the server computes it, the client can start checking the hash, while the server works on the next hash (in a pipelined manner). This performs dramatically better and also uses less memory as we don't need to hold a list of hashes, but only need to handle one hash at a time. There are two detriments to this approach: * The HTTP API relies on a JSON stream, which is not a standard REST-like pattern. However, since we implement both client and server, this is fine. * While the stream is on-going, we hold an open file handle on the server side while the file is being hashed. On really slow streams, this could hold a file open forever. Updates tailscale/corp#14772 Signed-off-by: Joe Tsai <joetsai@digital-static.net> Co-authored-by: Rhea Ghosh <rhea@tailscale.com> |
||
|---|---|---|
| .. | ||
| conffile | ||
| ipnauth | ||
| ipnlocal | ||
| ipnserver | ||
| ipnstate | ||
| localapi | ||
| policy | ||
| store | ||
| backend.go | ||
| conf.go | ||
| doc.go | ||
| fake_test.go | ||
| ipn_clone.go | ||
| ipn_test.go | ||
| ipn_view.go | ||
| prefs_test.go | ||
| prefs.go | ||
| serve_test.go | ||
| serve.go | ||
| store_test.go | ||
| store.go | ||