Skip to content

Latest commit

 

History

History
101 lines (79 loc) · 4.62 KB

TODO.md

File metadata and controls

101 lines (79 loc) · 4.62 KB
  • 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
    • 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 (partial)
    • clean up announced peer cache
      • only send a token to torrents really close to us
    • 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.
    • Ensure that if we query the "returned" nodes, they are even closer to our request than the responding node id was.

incoming peers:

  • error managing peer: expected extended handshake, but got Bitfield(<94 bytes>)
  • do not announce when merely listing the torrent

someday:

  • cancellation from the client-side for the lib (i.e. stop the torrent manager)
  • favicons for Web UI

desktop:

  • on first run show options
  • allow to change options later (even with a session restart)
  • look at logs - allow writing them to files? Set RUST_LOG through API

persistence:

  • store total uploaded bytes, so that on restart it comes back up

efficiency:

  • once the torrent is completed, we don't need to remember old peers

refactor:

  • session persistence: should add torrents even if we haven't resolved it yet

  • 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

  • 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

  • reopen:

    • in general, the only time the file should be write-only, is when it's live and not yet fully downloaded
    • initializing: open read-only if file has all pieces
    • on piece validated open read-only all files that were copleted
    • would be nice to have some abstraction that walks files and their pieces
    • nit: optimize open write/read/write right away on first start
    • peers: if finished they are all paused forever, but if we change the list of files, we need to restart them
  • opened_files: track HAVE progress

    • actually track
    • show in API and UI
    • refresh when downloading (it doesn't somehow)
    • on restart, this is not computed, compute
  • send cancellation to peers who we stole chunks from

  • don't account for stolen pieces in mesuring speed

  • file priority

  • start/end priority pieces per selected file, not per torrent

Streaming:

  • I want to stream files even if they are not checkboxed.

Other:

  • keepalive is useless, the tieout is 120s, and read timeout is 10s. Need to send keepalive only if nothing was done recently.
  • url should have the filename
  • reopening files: get rid of it!!! Even on Windows it should be alright - no need to reopen them.