cratetorrent
cratetorrent copied to clipboard
vimpunk
A BitTorrent V1 engine library for Rust (and currently Linux)
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.
It looks like github actions are free? If so, we should set up one to run unit tests and a few integration tests (not all to save time as we'd...
Because there is no real reason to do so: cratetorrent doesn't have much config files so there is nothing to contain as with transmission, and everything else is configurable (listen...
Currently cratetorrent unchokes a new peer unconditionally. This needs to change as upload slots need to be capped. Otherwise cratetorrent might take up most of host's upload bandwidth.
Unit and integration tests. Currently unsure how to do this with the container based approach. Maybe it's possible to block container links for a short time? As for unit tests,...