Live data from Hacker News

Building a BitTorrent client from the ground up in Go (2020)

blog.jse.li

71–80 of 93 posts

Re: Building a BitTorrent client from the ground up in Go (2020)

#71
post #4

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

It's worth noting that this is a paid service offering some free courses for a limited time. The BitTorrent course does not appear to be free at the moment.

Re: Building a BitTorrent client from the ground up in Go (2020)

#72

Earlier 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 :-)

Yeah. I was working on [0] for a while (I might get back to it when I have more time) and implemented a chunk of the protocol with an eye for a more scalable libtorrent replacement, and it's not entirely trivial. Even things like the piece picker get trickier at scale.

[0]: https://dgroshev.com/blog/torrentdyne-encryption/

Re: Building a BitTorrent client from the ground up in Go (2020)

#73
post #15

Earlier quoted context omitted.

> Go is the go-to-language for complex networking situations And Elixir / Erlang for serious ones.

Rarely on the client side.

Why though, especially with Phoenix? (HTML HEEx, etc.)

Re: Building a BitTorrent client from the ground up in Go (2020)

#75
post #11

Earlier 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…

Sure, I didn’t mean to suggest that it was impossible to handle, just that it was an edge case that you needed to explicitly handle and which a minimal implementation of the protocol might be likely to leave out.

Re: Building a BitTorrent client from the ground up in Go (2020)

#76
post #33
post #26

Earlier 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…

Check this out for a nice explanation of why tit for tat is a good strategy for the repeated Prisoner's dilemma: https://ncase.me/trust/

Re: Building a BitTorrent client from the ground up in Go (2020)

#77
post #6

This 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.

> Go is the go-to-language for complex networking situations.

laughs in elixir

Re: Building a BitTorrent client from the ground up in Go (2020)

#78

Earlier 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…

> Unfortunately, BEAM VM is very slow compared to multiple other languages including Go.

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)

#79
post #39

Earlier 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.

Became adware

Re: Building a BitTorrent client from the ground up in Go (2020)

#80
post #41

Earlier 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

Tixati is simple in the same way Deluge is simple. Because of this they both lack a lot of the quality of life things out of the box that qBittorrent provides.
Post reply on HN