vimpunk
vimpunk
https://github.com/mandreyel/cratetorrent/pull/95 introduced a fallback for disk writes on other platforms. It currently uses a less efficient approach than the Linux positional vectored IO APIs as they are not present on...
## Pre-alpha - [x] Perform a single in-memory download of a file with a single peer connection if given the address of a seed and the path to the torrent...
There's really no need to make cratetorrent Linux-only. The only places that rely on platform specific APIs are: - https://github.com/mandreyel/cratetorrent/blob/master/cratetorrent/src/disk/io/file.rs#L83 - https://github.com/mandreyel/cratetorrent/blob/master/cratetorrent/src/disk/io/file.rs#L141 - and uses of `/tmp` in tests an...
This is probably more optimal too, as per https://github.com/tokio-rs/mini-redis/blob/master/src/db.rs#L29.
It was intentionally kept simple to push for mvp. Afterwards, it would be a candidate for optimization. Possible ideas: https://blog.libtorrent.org/2011/11/writing-a-fast-piece-picker/
Currently we wait for disk IO to run to completion. We could hash piece, notify torrent of piece completion, and then attempt a write. This would mean that a failed...
Most clients will read-ahead blocks after a requested piece. If a peer is sufficiently fast, we should opt to download the whole piece from a single peer so that only...
The periodic (1s) torrent tick needs to do the following: - [x] remove finished peer sessions (#64) - [x] request more peers from tracker (#63) - [x] should connect peers?...
While this simplifies the logic a great deal, it uses up more resources without much need.