the thing actually works pretty good now

This commit is contained in:
Igor Katson 2021-06-27 01:14:08 +01:00
parent 0f431621b9
commit 5c5cf3c24a
2 changed files with 26 additions and 5 deletions

24
TODO.md
View file

@ -8,5 +8,27 @@
- [ ] per-file stats
- [ ] per-peer stats
- [ ] slow peers cause slowness in the end, need the "end of game" algorithm
- [ ] will require implementing cancel message
someday:
- [ ] cancellation
- [ ] cancellation from the client-side for the lib (i.e. stop the torrent manager)
# concurrency
it's fucked up now, so need to rethink.
Sequencing:
- when the peer sends bitfield
- update its bitfield
- this can only happen at the start. But it can also NOT happen at all (if the peer wants to download)
- so we actually cannot use it as a trigger to start the "uploader" of it (where we upload to it)
- however both this and "have" we can use as a trigger to start the "downloader" part of it
- when the peer sends "interested"
- when the peer sends "have"
- update its bitfield
"peer downloader":
- if started, means there was some initial interest
- if we are unchoked:
- fetch new pieces forever from the queue, send requests

View file

@ -791,11 +791,11 @@ impl TorrentManager {
.peers
.update_bitfield_from_vec(handle, bitfield.0);
if !self.am_i_interested_in_peer(handle) {
self.inner.locked.write().peers.drop_peer(handle);
// self.inner.locked.write().peers.drop_peer(handle);
return;
}
// Additional spawn per peer.
// Additional spawn per peer, not good.
spawn(
format!("peer_chunk_requester({})", handle),
self.clone().task_peer_chunk_requester(handle),
@ -1375,8 +1375,7 @@ impl TorrentManager {
match tokio::time::timeout(keep_alive_interval, outgoing_chan.recv()).await {
Ok(Some(msg)) => msg,
Ok(None) => {
// we were closed
return Ok(());
anyhow::bail!("closing writer, channel closed")
}
Err(_) => MessageOwned::KeepAlive,
};