2.1 KiB
- when we have the whole torrent, there's no point talking to peers that also have the whole torrent and keep reconnecting to them.
- per-file stats
- [x (partial)] per-peer stats
- use some concurrent hashmap e.g. flurry or dashmap
- tracing instead of logging. Debugging peers: RUST_LOG=[{peer=.*}]=debug test-log for tests
- reopen read only is bugged
- initializing/checking
- blocks the whole process. Need to break it up. On slower devices (rpi) just hangs for a good while
- checking torrents should be visible right away
- server persistence
- it would be nice to restart the server and keep the state
- torrent actions
- pause/unpause
- remove including from disk
- DHT
- for torrents with a few seeds might be cool to re-query DHT once in a while.
- it's sending many requests now way too fast, locks up Mac OS UI annoyingly
- After the search is exhausted, the client then inserts the peer contact information for itself onto the responding nodes with IDs closest to the infohash of the torrent.
- Bad actors:
- Ensure that if we query the "returned" nodes, they are even closer to our request than the responding node id was.
someday:
-
cancellation from the client-side for the lib (i.e. stop the torrent manager)
-
favicons for Web UI
refactor:
-
where are peers stored
-
http api pause/unpause etc
-
when a live torrent fails writing to disk, it should transition to error state
-
something is wrong when unpausing - can't finish. Recalculate needed/have from chunk tracker.
-
silence this: WARN torrent{id=0}:external_peer_adder: librqbit::spawn_utils: finished with error: no longer live
-
start from error state should be possible from UI
-
if the torrent was completed, not need to re-check it
-
checking is very slow on raspberry checked. nothing much can be done here. Even if raspberry's own libssl.so is used it's still super slow (sha1)
-
.rqbit-session.json file has 0 bytes when disk full. I guess fs::rename does this when disk is full? at least on linux. Couldn't repro on MacOS