Slashdot Mirror
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?"
It will be replaced when our ISP monopolies makes it so difficult to use bittorrent, another way must be created. Destruction brings creation.
BitTorrent might not be replaced until tracker operators learn what an average is. A lot of private trackers require their users to keep their share ratios at or near 100%. But it's mathematically impossible for everybody to have a share ratio greater than 100%. Share ratio is upload divided by download, but across a whole swarm, the sum of upload will equal the sum of download, making the average share ratio 100%. One can't seed unless there's a downloader on the same swarm. So what are people who get in on the tail end of a swarm, where no downloader shows up for days at a time, supposed to do to keep their share ratios up to the tracker's standard?
once you've decided to download the torrent, why do you just want this one single instead of the entire discography in flac and mp3?
Because I want to be able to download other things during the same month without having to pay prohibitive overages.
Nowadays there is such thing as "trackerless torrents". No idea how it works, but it works. A while ago I tried to download some torrent, but the single listed tracker in the .torrent was down. Nevertheless soon the download started, like magic :-) And once one peer was found, many more followed quickly thanks to peer exchange.
BT has in a way been replaced several times already. The protocol from 10 years ago has evolved a lot (will the original BT client even be able to handle to current torrents?), with additions like peer exchange, DHT, magnet links and encryption. The idea behind BT is brilliant and simple, and as such will always live on. It solved most if not all problems from the original P2P protocols: the P2P issue itself (too many downloaders on a single peer), disappearing peers (now you have more than one - download will continue from other peers), and overall download speed. The protocol was found to have some problems itself, most notably the centralised tracker, which is also solved now. The problems that remain are the finding of content, for that there is still no solution to the current centralised databases (aka "torrent sites"), and longevity of the content: as soon as the last seeder stops seeding, the file is lost from the network.
And on top of it, it's not owned by a single for-profit organisation like Napster or LimeWire. When that company goes out of business, the protocol is out, and something new is needed. BT will live long I think. It's an open and free protocol, allowing for it to evolve and have people add features to it. There is no "single point of failure" - by design.
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.
If all else fails, immortality can always be assured by spectacular error.
Shocking, Comcast follow the law and serve the notices. They should be on the side of the little guy who just needs to watch Game of Thrones for free or he might be bored! The ignominy!
I think the legal balance is just as important. The fact that "BitTorrent" isn't one service or one network but that each site offer their files individually and the Ubuntu torrent has nothing to do with those on The Pirate Bay. That detached the technology and those building the tools from the shadier uses of it. Oh, they've rattled their sables a bit but never really had an legal grounds to shut BitTorrent itself down, unlike Napster, Grokster, Limewire and so many others.
And despite the best efforts to shut down torrent sites, many of them still operate very much in the open. The fact that The Pirate Bay has been all over the media and is in the top 100 most popular sites on the web means they've walked a very fine line and come down on the right side - at least for now. You didn't have to look that very hard in the past either to find it, but it was not that obvious to everyone and their dog.
I think something like TPB model is there to stay, if necessary they'll just move it to be a TOR onion site, still centralized but anonymous. Not the content itself as that'd be sloooow, just the site itself. For the moment that is simply not necessary, but there's now other ways should the public torrent sites lose while still keeping the things that made it a success.
Live today, because you never know what tomorrow brings
I'm not too pleased with Cox's 200GB cap that amounts to only a few percent of what my 15mbps down/2mbps up is theoretically capable of.
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
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.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524