BitTorrent Turns 10

ktetch-pirate writes "On this day, 10 years ago, Bram Cohen released the first bittorrent client to the public. Most P2P protocols have had a rapid rise and then a drop-off as the subsequent 'best thing' has come out, but after 10 years, nothing has bested bittorrent, and it still remains king of the P2P castle. Just when will it be replaced?"

Comments

When...

[smileygladhands]

It will be replaced when our ISP monopolies makes it so difficult to use bittorrent, another way must be created. Destruction brings creation.

Re:Pretty much never?

[mrogers]

Going distributed is THE way of stopping people from shutting you down.

But ironically, what BitTorrent got right (and it pains me to admit this, because I'm a big fan of pure P2P solutions) was centralising the hard parts - search and peer location - and distributing the easy part - content distribution.

Another area where BitTorrent struck the right balance between pure P2P and pure centralisation was in content curation. Gnutella made it incredibly easy to share a file, but the result was a ton of low-quality, badly-labelled, nearly-identical files. BitTorrent made it just hard enough that only a few, relatively dedicated people would create torrents, and everyone else would just redistribute them. I don't think that was a conscious design decision, but it happened to hit the sweet spot.

Re:Pretty much never?

[klapaucjusz]

Nowadays there is such thing as "trackerless torrents". No idea how it works, but it works.

It uses a technique known as a Kademlia Distributed Hash Table (DHT). It's a rather tricky algorithm, which turns out to work beautifully for this particular application.

--jch

Re:Pretty much never?

[CharlyFoxtrot]

We're in the silver age of music piracy. The golden age was Napster: everyone had their mp3's in folders instead of managed by applications like iTunes and everything was shared by everyone by default. You could find the most obscure songs. To me it was like a preview of what the internet always promised: a huge library where you could access any data (in this case music) that was out there. A little glimpse of the internet's true potential.

Re:Pretty much never?

[Tacvek]

Combining multicast support which is certainly be bettter and more widely supported than it's today is. The reason is looming and it's HD-IPTV. Unicast HD-IPTV is a bandwith consumptive hog and the only practical way is to use multicast for it. That forces many organisations which did not previously bother configuring it reconsider and this will open doors to other applications using it too.

I strongly doubt that. Consider that AT&T uses multicast for their U-Verse service. The problem is that they provide no way to create your own multicast streams. They have no interest in allowing other applications to use it. Why would they? The multicast gives their service a serious cost advantage compared to other live streaming services. Because it is generally viewed as a separate TV service, most proposed net-neutrality regulations would not require them to open it up.

To the best of my knowledge there is no real standards for negotiating multi-cast between autonomous systems. Even if there were, the fact that the packets can multiply inside a network (when they reach a router with subscribers on more than one of the connected (sub)networks) makes setting up peering agreements difficult.

Transit agreements between ISPs generally assume that one packet sent in results in one packet leaving the network, or being delivered to a machine inside the network. With multicast between distinct autonomous systems, that one packet in could result in 100 packets being delivered to in network machines, and potentially one packet to each connected network. How should that be counted for billing?

If each resulting packet is counted, that would require network changes to track how many in-network machines it was delivered to. If it were counted as just the one packet for this network, plus one more packet for each connected peer or transit provider it reached, the required changes would be much smaller.

However in either case that would be really unfair to the sender of the packet, who has no way of knowing how many times an individual packet would be counted. It would also be rough on intermediate networks who may try to track usage and switch packets between multiple transit providers such as to minimize costs. They would only know that they sent one packet of some specific size to a given transit provider who may count it as many more packets.

The whole thing is very awkward. After all despite those issues, ISPs could benefit from the same number of users with the same style of usage resulting in many fewer total packets needing to be sent through the oversubscribed links from the core networks to last mile.