CodeCrafters has a BitTorrent client building challenge that I watched Jon Gjengset do on a stream, if someone wants to try and build their own client in an iterative and checked way. https://app.codecrafters.io/courses/bittorrent/overview
Building a BitTorrent client from the ground up in Go (2020)
71–80 of 93 posts
Re: Building a BitTorrent client from the ground up in Go (2020)
#72Earlier quoted context omitted.
Few more challenges: - seeding a million active torrents (this is entirely possible and needed but drives a lot of architecture) - a UI for a million active torrents - be nice to trackers (keep-alive, batched reports; again, architecture gets tricky, iirc libtorrent can't do that still) - correct pipelining - congestion control on uTP - I/O scheduling/batching - testing all of the above It is quite a lot.
Looks like we have same experience with torrents :-)
Re: Building a BitTorrent client from the ground up in Go (2020)
#73Re: Building a BitTorrent client from the ground up in Go (2020)
#74Re: Building a BitTorrent client from the ground up in Go (2020)
#75Earlier quoted context omitted.
IIRC, when both peers only have some subset of pieces, they are meant to “trade” with each other, and so will eventually drop low value peers for higher value ones. Aside from the adversarial case, this helps optimise for being nearer to the people you are sharing with, since torrents are global. In practice, BitTorrent really needs seeders who have downloaded the entirety of the file to be fast for everything except…
For the regular case, 5-10 seeders will hold up an entire torrent indefinitely and without any issues. The contribution leechers make drops off very quickly if good seeders exist. My algorithm did favour the best peers (both upload and download) but a few years ago switched to a "seeded" ordering to prevent bad behaviour clients dumping or starving new peers. The garbage uploaders are not an issue. You can isolate pe…
Re: Building a BitTorrent client from the ground up in Go (2020)
#76Earlier quoted context omitted.
Sufficiently evolved torrent clients follow a tit-for-tat protocol: - If you're nice with me I'll be nice with you - If you're mean with me I'll be mean with you This is the best answer for the Prisoner's dilemma ( https://en.wikipedia.org/wiki/Prisoner's_dilemma ) on the long run, ie a situation where peers don't trust each other but will both gain if both cooperate. In bittorrent it's typically implemented as follo…
> [tit for tat] is the best answer for the Prisoner's dilemma on the long run This is fascinating. Have there been any simulations about this? I'm sure they've looked into this in game theory, but I'm wondering if you have a big swarm of torrent clients, does the scale of the population change the outcome, or is it the same? (It seems like it would be wise when designing the torrent clients to run such simulations, s…
Re: Building a BitTorrent client from the ground up in Go (2020)
#77This looks simple not only because the article is written well but also because Go is the go-to-language for complex networking situations. Doing things in parallel, even pipelining? This would make quite some spaghetti algorithm in C/C++, even async rust/python world would not look so clean as in Go. This is clearly a big strength of the language.
laughs in elixir
Re: Building a BitTorrent client from the ground up in Go (2020)
#78Earlier quoted context omitted.
> Go is the go-to-language for complex networking situations And Elixir / Erlang for serious ones.
Unfortunately, BEAM VM is very slow compared to multiple other languages including Go. It's great when starting out with a few developers, however, since Go and Rust are much more performant, it is possible to hire several more Go or Rust developers with the server cost savings instead of being tied to Elixir. There is always a trade off between easy to use and high performance. But, yeah, if I was going to bootstrap…
for cpu bound tasks? sure. but we are talking in the context of networking. elixir is going to absolutely smoke go for applications requiring a lot of simultaneous connections. We can already see it in actionable vs phoenix channels. channels supports a magnitude order more simultaneous websocket connections per machine.
ps: libraries like rustler exist. you can take the cpu intensive stuff and offload it to a module written in rust when you really need to squeeze some perf out.
Re: Building a BitTorrent client from the ground up in Go (2020)
#79Earlier quoted context omitted.
For me, the hardest part of building a good BT client (or any software, really) is getting the UX right. These days, I use QB after uTorrent's downfall, but even after all these years, its UX still isn’t quite there.
As someone who stopped torrenting around 2015 or maybe 2016, what happened to uTorrent? Also RIP what.cd, I still am sad that it is gone.
Re: Building a BitTorrent client from the ground up in Go (2020)
#80Earlier quoted context omitted.
qBittorrent + VueTorrent is not perfect, but it's hard to find anything better. If you haven't tried it, take a look. https://github.com/VueTorrent/VueTorrent
https://tixati.com