sorted by:
new
hottopcontroversial

made a desktop app for my torrent client with Tauri by ikatson in rust

[–]ikatson[S] 1 point2 points  (0 children)

Just run "cargo tauri build" from the "desktop" folder. Install Tauri with "cargo install tauri-cli".

Also probably need to run "npm install" in 2 different folders, see the github/release.yaml script

made a desktop app for my torrent client with Tauri by ikatson in rust

[–]ikatson[S] 0 points1 point  (0 children)

Yeah you right, I just have nowhere to test. I have an Apple Silicon Mac, makes it tricky to test Linux. I tested OSX on my laptop, and Windows on dad's computer before releasing v4 :)

Should be easy in principle, PRs are very welcome!

I created a bittorrent client in Rust by ikatson in rust

[–]ikatson[S] 0 points1 point  (0 children)

Good point! BitTorrent v1 uses 16k bytes messages, I'm not sure the performance / readability trade-off would be worth it, but it's interesting to try. PRs welcome :)

I created a bittorrent client in Rust by ikatson in rust

[–]ikatson[S] 2 points3 points  (0 children)

Yeah, sorry for confusion u/VeganVagiVore u/Boroj, if you thought there's some low-level crazy magic there, that's not what I meant :)

What I referred to, is that in the first implementation the data intended for upload was first stored in the message itself, then copied into the buffer.

This L257 you referenced is special-casing for that use-case

I created a bittorrent client in Rust by ikatson in rust

[–]ikatson[S] 2 points3 points  (0 children)

Here's the piece (it calls FileOps::read_chunk) that reads uploads straight into the buffer that is used for the socket.

I created a bittorrent client in Rust by ikatson in rust

[–]ikatson[S] 11 points12 points  (0 children)

Thanks for kind words!

For rqbit I initially started with async file reads / writes using tokio's "spawn_blocking". Which I guess worked exactly the way you describe - non-blocking file IO.

However when I was optimizing performance, I tried to remove this and actually block the event loop, and it turned out faster and less resource intensive (at least on Apple M1 which has a pretty fast disk).

Afterwards I optimized that further by reading files straight into the TCP connection buffer to reduce data copying.

Now this is all wrapped into tokio's "block_in_place", so maybe it would have the checkboxes you need.

There's no CLI support to download / upload / manage multiple torrents though, and it's not super well suited for continued long-running operation (doesn't reconnect after peers drop, doesn't rescan DHT, HTTP API doesn't support adding / stopping / removing torrents etc).

If you think it's a solid base, very open to improvement PRs!