rqbit/TODO.md at 14d7ee04eae9996e44855a55f3a574b5a797a226

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

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

torrent actions

DHT

bootstrapping is lame
many nodes in "Unknown" status, do smth about it
for torrents with a few seeds might be cool to re-query DHT once in a while.
don't leak memory when deleting torrents (i.e. remove torrent information (seen peers etc) once the torrent is deleted)
Routing table - is it balanced properly?
Don't query Bad nodes
[-] Buckets that have not been changed in 15 minutes should be "refreshed." (per RFC)
- Did it, but it's flawed: starts repeating the same queries again as neighboring refreshes don't know about the other ones, and DHT returns the same nodes again and again.
it's sending many requests now way too fast, locks up Mac OS UI annoyingly
store peers sent to us with "announce_peer"
announced peers should be persisted
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.

To do this, a
Ensure that if we query the "returned" nodes, they are even closer to our request than the responding node id was.