konspire vs BitTorrent: The hype, and not believing it
Posted: June 12th, 2003 | 3 Comments »Regular Slashdot readers will have already seen today’s piece about konspire, a kind of P2P/push combo that lets anyone publish data channels that are broadcast to subscribers using co-operative networking a la my current P2P favourite, BitTorrent. konspire’s creators make the comparison themselves in this document, in which they claim that their co-operative network beats out BT’s for speed and scalability.
I had a quick skim of the document and it felt wrong: firstly, BT clients start sharing files with other clients as soon as they have the first small chunk, whereas konspire clients wait for the whole file. Secondly, BT’s network isn’t tree-shaped, it’s a mesh, which is one of the reasons it works so well. Plus, the document assumes that anyone downloading a file with BT will close the client as soon as the download has completed, which is rarely the case. For more detail (plus a load of maths) check out these remarkably well-thought-out answers to a (somewhat clueless) question I posed in the Slashdot thread. One of the answers comes from the guy who wrote the document, another comes from the creator of Burst!, my current favourite client.
A few good links I found off the discussion:
- This paper from Microsoft Research is a deep investigation into co-operative networking, including using it for streaming.
- MLDonkey is a P2P uber-client that talks to all the popular networks (Gnutella[2], eDonkey, FastTrack (Kazaa), BT, Overnet, plus others) and is available for all platforms in one way or another (it’s a bit complicated…)
- NetLimiter is something I’ve wanted for ages: A bandwidth throttler for Windows, configurable on a per-app basis. (*nix users wanting this kind of thing should look at Trickle)
The concept of “channels” already exists for some BitTorrent users: some sites have RDF feeds of content, and BT users just click the link in their RSS feed reader.
I don’t imagine it’s too much of a jump to use a reader that automatically fetches links. A cron/perl/btheadless could do this with little effort I imagine.
Hi, I am from China.
I have read “BT vs Konspire” article too. I agree with you and feel that the author has very defensive attitude for his work.
I think the author has made a big mistake that no one has noticed. He assumed only one person download from one other person at one time. This is often not the truth, and of course carry out the result O(n). If we assume at one time 2 people can download from one person(it is so weak that in pratical often 5-6 people download from one guy). It is at once changed into O(2^n).
The speed depends on how short a block is. It explains why the figure in BT the relation of Leechers and Seeders at the begining is growing in exponential speed.
Like the following figure:
1—-+—————-+
2 1–+——+ 1–+——+
3 2 1-+-+ 1-+-+ 2 1-+-+ 1-+-+
4 3 2 1 1 2 1 1 3 2 1 1 2 1 1
5 4 3 2 2 3 2 2 4 3 2 2 3 2 2
5 4 3 3 4 3 3 5 4 3 3 4 3 3
5 4 4 5 4 4 5 4 4 5 4 4
5 5 5 5 5 5 5 5
We can take Konspire that a block is as long
as one file, usually as hundreds megabytes.
And one block in BT is 256K, so BT is much
much better than Konspire.
I am working at a p2p software in Chinese too, and hope to take part in your disscusion.
Please execute my poor English.
Thanks for the comment, Leo! You’re right, that’s one of many problems with the comparison document.
What kind of p2p software are you working on?
(And I should say that my Chinese is certainly worse than your English)