Slashdot Mirror
Bittorrent Implements Cache Discovery Protocol
An anonymous reader writes "CacheLogic and BitTorrent introduce an open-source Cache Discovery Protocol (CDP) that allows ISP's to cache and seed Bittorrent traffic. Currently, Bittorrent traffic is suffering from bandwidth throttling ISP's that claim that Bittorrent traffic is cluttering their pipes. This motivated the developers of the most popular Bittorrent clients implement protocol encryption to protect bittorrent users from being slowed down by their ISP's. However, Bram Cohen, the founder of Bittorrent doubted that encryption was the solution, and found (together with CacheLogic) a more ISP friendly alternative."
Given that a lot of torrents are copyrighted content, are ISPs really going to want to do this? The moment they start caching these files on their servers, they become a huge target for lawsuits.
when will this be implemented in azureus and utorrent? i appreciate bram's work immensely but i'm not too keen on his app...
Large print giveth, and the small print taketh away
CDP = Cisco Discovery Protocol
http://www.javvin.com/protocolCDP.html
It's no different than them hosting usenet servers. When contacted by copyright holders they are required to remove the infringing material(s). As long as they aren't actively monitoring what they're caching, they aren't required by law to do anything about it. +1 for legal precedence before lobbyists took over our government (at least the telecom portion).
On the cache the files are stored as file chunks, with only a reference to the file hash value, not the filename. So the ISP has no idea what is in the cache, so it is the same as the file being passed through their network.
And who doles-out the multicast group addresses? I think the problem is harder than you think at first glance.
Wouldn't this technology make your ISP a seeder? Now that would be fast.
The sender can multicast the file in a loop. The recipients will get the pieces starting from whenever they started "listening" on the ongoing multicast, and then get the earlier parts, when the sender finishes and starts over again.
This is far more efficient, than for the sender to push the same data to each client in parallel.
In Soviet Washington the swamp drains you.
Some people in networking research believe that the problem with Multicast (and even QoS) has nothing to do with scalability, but more with economics. Although in this case, ISPs would reduce traffic going through their network by enabling multicast, there is no popular method of accounting for internal traffic when multicast is enabled on all routers. For most ISPs this is unacceptable, since large customers are billed based on the amount of traffic sent. Since there's no economic model developed for multicast-traffic, ISPs would rather throttle back BitTorrent than enable multicast. Someone please correct me if I'm mistaken on any of these points.
Most networking researchers seem to believe multicast is technologically feasible and helpful, which is why a lot of Internet architecture research seems to provide methods for multicast, even though hardly anybody uses it today.
A locality-aware swarming protocol can only discover other peers at the same ISP that are running at the same time, but a cache hosted by the ISP is always running and can serve content that was downloaded by another client earlier (sort of cooperative prefetching). Also, the bandwidth between the cache and a customer is usually going to be much higher than the bandwidth between two customers because of asymmetric connections.
It's not GNU/Linux distributions that have caused ISPs to decide to bandwidth throttle bittorrents.