Live data from Hacker News

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

blog.jse.li

91–93 of 93 posts

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

#91
post #23

Earlier quoted context omitted.

> Now I wonder how clients protect themselves against abusers (i.e. people who never upload a single bit but only download). It's called leeching, and it depends. It's typically considered good etiquette to upload as much as you download and that's usually enough, but it can be enforced https://en.wikipedia.org/wiki/Leecher_(computing)

I have the opposite problem, many things I download seem so well-seeded (seedboxes?) that I rarely achieve any sort of respectable ratio even if my uplink idles most of the time. It might be client problem but I haven't found much anyone discussing this. TAKE MY BITS!

If the torrent is already well-seeded it's ok, a 1567th seed won't make a difference so don't bother with them. It's the less seeded torrents where you can put some efforts and do something good.

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

#92
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…

It's only the best answer if the other party is bothering to seek the best answer in real time, and in ways that you can't predict. If your opponent is governed by some algorithm, which is the case for torrent clients, you may need to depart from tit for tat in order to break them out of a needlessly adversarial mode. Or, if you're feeling like the bad guy today, you might need to depart from tit for tat to put them…

If a peer doesn't respond quickly enough they can be disconnected from and marked as bad. Even if they had good intentions their latency might be too high and it's good to disconnect from them.

Check out this very nice link from a sibling comment: https://ncase.me/trust/. You'll see that an adversarial node either is too adversarial and will be cut off, or still gives just enough to not be cut off but if there are other, more cooperative nodes, they will be favored. Being adversarial doesn't work in the long run.

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

#93
post #33

Earlier quoted context omitted.

> [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/

Thank you, this is great!
Post reply on HN