The BitTorrent Protocol Specification v2 • Hacker News Board

Re: The BitTorrent Protocol Specification v2

#111

Post by pdimitar » Sat, Aug 12, 2017, 5:51 PM UTC

the8472 wrote: post #10

jzelinskie wrote: post #6

This update to the spec is a modest change that's largely a preemptive reaction to SHA1 being broken; large portions of BitTorrent are designed around the 20-byte length of a SHA1 checksum. They've decided to move forward with SHA256 truncated to 20 bytes to avoid incompatibilities with existing infrastructure such as the Mainline DHT. Beyond the hashing algorithm, some important additions that were previously propos…

The DHT BEPs specify a network that is only barely related to the bittorrent core protocol, they can already be used independently, and some people do. > I feel like trackers were largely overlooked in this update, but I'm biased because I work on a popular tracker. Yes, we did not pay much attention to trackers, but BEP52 basically seized the opportunity to do some incompatible changes we always wanted to do anyway…

More generic question, apologies if it feels inserted without relevance:

Did you guys talk with the IPFS team? Do both of you have a desire to start bringing both families of protocols and technologies closer together?

I feel in this age we must make de-fragmentation of efforts our topmost priority.

Re: The BitTorrent Protocol Specification v2

#112

Post by pdimitar » Sat, Aug 12, 2017, 6:11 PM UTC

freeone3000 wrote: post #79

nailer wrote: post #75

Earlier quoted context omitted.

Perhaps because a lot of content is streamed live? Streaming wants us to download A, B, C, D just in time. Bottorrent (simplified) wants me to download piece P, you to download piece G, then I get P from you and you get G from me. There are Bottorrent streaming apps but they kind of mess with the nature of BT. OTOH things like RPM/Deb/WindowsUpdate etc it would make great sense.

World of Warcraft (used to?) patch with Bittorrent.

All Blizzard games make heavy use of BT-like technology for downloading patches to this day. It's extremely efficient. A 300MB patch to Overwatch downloading with the max speed my ISP is giving me (100 Mbps). It's a matter of 30-40 seconds.

Re: The BitTorrent Protocol Specification v2

#113

Post by pdimitar » Sat, Aug 12, 2017, 6:16 PM UTC

smegel wrote: post #31

Pity we will never see a genuine version of uTorrent that will support it. That was a real loss.

I found qBittorrent to be very adequate and full of good options to provide you granularity on how would you like to manage your upload traffic.

Re: The BitTorrent Protocol Specification v2

#114

Post by the8472 » Mon, Aug 14, 2017, 3:38 PM UTC

ue_ wrote: post #77

Klathmon wrote: post #71

I have to admit, BitTorrent is one of the things I took for granted. I never really thought about the details of how it works, or the really really impressive feats that were accomplished to get it to work. I knew it was a really good technology, but reading this and the comments here puts it on a whole other level. Why isn't this technology talked about more? Why are blockchains the big "thing" right now with people…

I wanted to implement a distribured imageboard over bittorrent but I quickly realised it's hard to add data after the initial publication, and further to verify it, and the nature of trackers may make it prone to censorship. So I gave up.

> but I quickly realised it's hard to add data after the initial publication

combining BEPs 46 and 50 enables rapid updates of torrents, but they are fairly new and there are no implementation designed with low latency in mind. Most bittorrent implementations focus on large amounts of data and throughput, so this use-case is not well served in practice even though the protocol could support it now.