Dan Oxlade
Dan Oxlade
How is one supposed to safely evict entries? I'm going off of the `cachetools` documentation [here](https://cachetools.readthedocs.io/en/latest/) and thought that to clear the cache I would need to do something like...
Creating a new `StorrentDownload` actor instance currently assumes you're starting from scratch. Use the persistence actors to fetch the state of the partial file(s) and prime any other actor state
When a torrent download is completed successfully and the file is written out, `StorrentDownload` should send a notification of completion (to parent?) and `stop` itself and hence the entire actor...
Both attempted download implementations _pull_ the piece and piece to download. This isn't in the reactive spirit. It would be nice if a _download manager_ were notified when we're unchoked...
There us currently no support for remote peers downloading from us. This is obviously a complete violation of the BitTorrent protocol.
`io.github.oxlade39.storrent.persistence.FilePersistence` uses a Set of offsets to keep track of the current sequential bytes. When offsets overlap they are equivalent to the total offset from min start to max end....
See _io.github.oxlade39.storrent.peer.Pipeline#maxSize_ At the moment this is just some arbitrary value I've chosen.
See [End Game](https://wiki.theory.org/BitTorrentSpecification#End_Game). In brief, the current downloader only downloads unique pieces from unique peers. When the last few pieces are being downloaded they 'trickle' through slowly on individual download...
The existing http tracker sends a default/initial TrackerRequest. The tracker should be modified to be aware of the state of the current download and send correct information to the tracker,...