Examining Bittorrent

ToyKeeper and other wrote in with this: "The Register published a detailed analysis of BitTorrent traffic and user habits today, focusing on four aspects: availability, integrity, download speeds, and ability to withstand flash crowds. BitTorrent carries 53% of all P2P traffic (or ~35% of all 'net traffic), and this paper helps explain why. Also included are data about torrent lifetime, network poisoning, response during downtime or attacks, and lots of pretty charts. A few performance problems are revealed, which will hopefully be addressed in future p2p systems." The original paper (pdf) is available.

Comments

Such an unused potential

[vincob]

There is such a powerfull distribution mechanism in P2P network, if only the studios/majors/etc would understand it and use it instead of fighting it, their market could explode, while having no distribution costs, their custermers would provide the distribution mechanisms.

But I'm afraid they are not going to get it in time.

My dream about a P2P PVR:
http://www.oberle.org/blog/2004/08/02/a-p2p-video- recorder-box/

Slashdot effect salve

[Doc Ruby]

The real breakthru for distributed P2P tech will come when someone publishes a BitTorrent content distributor that can be plugged transparently in front of an HTTPD. So I hit http://www.whatever.com , and get my HTTP response, with cache and timing headers intact. But behind the scenes, the "www" host is really the entry point to a distributed server network, a pool of interconnected "torrent" servers that transparently balance the traffic throughout the capacitance of the protocol network. Those servers actually tap the "real" HTTPD behind that network only to check for updated content, which is distributed to the network on demand, to be passed through to requesting clients. The clients speak only HTTP, and can't tell the difference between the real HTTPD and the distributed network proxies.

As long as I'm asking Santa, I'll be more specific. That "www" host has its DNS resolved by the nameserver at whatever.com , which hands out IP#s of the other "torrent" servers distributed around the "Web". torrent servers get the IP# of the real host at whatever.com, so they get content. There are problems: HTTPS requires each serialized object requested/replied to be encrypted with/for the actual private key of the requesting client, unknown until the request is made. And "CGI" or other dynamic content creates a huge space of permuted object states. But, Santa, Google figured out how to deal with all this in a centralized datacenter, and they're damn fast. Get the elves on this, and children around the world will sleep with visions of sugarplums streaming to their download directories.