From df282ae9d86c73b1f614e186baf1806e82ab11de Mon Sep 17 00:00:00 2001 From: Igor Katson Date: Mon, 28 Jun 2021 21:06:00 +0100 Subject: [PATCH] Dude this is like production ready! --- Makefile | 8 +++++++- TODO.md | 26 ++++---------------------- crates/librqbit/src/peer_connection.rs | 4 ++-- crates/librqbit/src/torrent_manager.rs | 3 ++- 4 files changed, 15 insertions(+), 26 deletions(-) diff --git a/Makefile b/Makefile index f7f1550..4e967ad 100644 --- a/Makefile +++ b/Makefile @@ -4,4 +4,10 @@ sign-debug: codesign -f --entitlements resources/debugging.entitlements -s - target/debug/rqbit sign-release: - codesign -f --entitlements resources/debugging.entitlements -s - target/release/rqbit \ No newline at end of file + codesign -f --entitlements resources/debugging.entitlements -s - target/release/rqbit + +build-release: + cargo build --release + +install: build-release + cp target/release/rqbit "$(HOME)/bin/" \ No newline at end of file diff --git a/TODO.md b/TODO.md index 9077725..ea7e086 100644 --- a/TODO.md +++ b/TODO.md @@ -5,30 +5,12 @@ - [x] use the "update_hash" function in piece checking - [ ] signaling when file is done +- [ ] + - [ ] per-file stats - [ ] per-peer stats -- [ ] slow peers cause slowness in the end, need the "end of game" algorithm - - [ ] will require implementing cancel message +- [x] slow peers cause slowness in the end, need the "end of game" algorithm someday: -- [ ] 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 \ No newline at end of file +- [ ] cancellation from the client-side for the lib (i.e. stop the torrent manager) \ No newline at end of file diff --git a/crates/librqbit/src/peer_connection.rs b/crates/librqbit/src/peer_connection.rs index 576f4d4..dadbdf0 100644 --- a/crates/librqbit/src/peer_connection.rs +++ b/crates/librqbit/src/peer_connection.rs @@ -123,7 +123,7 @@ impl PeerConnection { WriterRequest::Message(msg) => msg.serialize(&mut buf), WriterRequest::ReadChunkRequest(chunk) => { // this whole section is an optimization - + buf.resize(PIECE_MESSAGE_DEFAULT_LEN, 0); let preamble_len = serialize_piece_preamble(&chunk, &mut buf); let full_len = preamble_len + chunk.size as usize; buf.resize(full_len, 0); @@ -280,7 +280,7 @@ impl PeerConnection { // Theoretically, this could be done in the sending code, so that it reads straight into // the send buffer. let request = WriterRequest::ReadChunkRequest(chunk_info); - info!("sending to {}: {:?}", peer_handle, &request); + debug!("sending to {}: {:?}", peer_handle, &request); Ok::<_, anyhow::Error>(tx.send(request).await?) } diff --git a/crates/librqbit/src/torrent_manager.rs b/crates/librqbit/src/torrent_manager.rs index f9f6138..0bfe6f7 100644 --- a/crates/librqbit/src/torrent_manager.rs +++ b/crates/librqbit/src/torrent_manager.rs @@ -286,6 +286,7 @@ impl TorrentManager { match this.tracker_one_request(tracker_url.clone()).await { Ok(interval) => { event = None; + let interval = 30; let duration = Duration::from_secs(interval); debug!( "sleeping for {:?} after calling tracker {}", @@ -295,7 +296,7 @@ impl TorrentManager { tokio::time::sleep(duration).await; } Err(e) => { - error!("error calling the tracker {}: {:#}", tracker_url, e); + debug!("error calling the tracker {}: {:#}", tracker_url, e); tokio::time::sleep(Duration::from_secs(60)).await; } };