Slashdot Mirror
A Blog With Unlimited Bandwidth (Beta 1.2)
jcr13 writes "konspire2b is a new content distribution system that essentially turns the standard p2p model upside down. This simple change gives the network several nice properties, including log-bounded distribution times (logarithmic in the number of nodes that receive a file) and a refreshingly different (and somewhat blog-like) user-interaction model. Comparisons have been made to other systems, including BitTorrent (with in-depth analysis), but k2b stands alone as a unique system tackling a different problem than other p2p systems. Recent Slashdot attention gave the network an effective stress test and provided the first real-world measurement results. The new beta1.2 release contains fixes for all of the issues encountered during this traffic surge."
This looks nifty.
However, I see a potential gotcha for those who will inevitably use this to distribute mp3s and the like: You (the channel owner) are much more overt as a *broadcaster* of content you don't own the copyright to, rather than merely someone who makes a file available. Rather than both the uploader AND downloader choosing to share a file, the downloader is (to an extent) not picking specific content to obtain.
To some degree, it's an irrelevant distinction, probably even in a *purely* legal context. But being able to (accurately) use a term like "broadcaster" rather than "trader" of copyrighted content is the kind of statement that can have a powerful effect.
And, of course, the channel owners are more direct targets of legal action than the downloaders in this scenario (since the downloader may not obtain the file from the "original" broadcaster -- the owner, correct?); Kazaa and the like expose both the uploader and the downloader more or less equally.
Not sure how much difference that will make in the grand scheme of things, really. But at the least, I'd say that makes this system a somewhat more visible target for the R.abid I.nfernal lawyers A.ssociation of A.merica...
Xentax
You shouldn't verb words.
Yes, it's crap.
I'll follow the author and call the originating Torrent client a "server" but it's not really.
There are a couple of unjustified assumption here.
One is that the "server" can only serve one "client" at a time. This isn't a justified assumption. Several "client/servers" can download from a given Torrent "client/server" at once.
The second assumption is that all clients join simultaneously. This circumstance is theoretically possible, but is pretty damned unlikely.
The third assumption is that all clients can download at the same rate. I'm going to stipulate this for now, because I don't want to complicate things too much.
If we assume a server can serve more than one client simultaneously, and that clients join at least one block apart, it goes like this:
Alice joins first and downloads 2 blocks.
Bob joins next, and downloads Alice's two blocks, plus two from the "server". At the same time, Alice downloads another two blocks from the server.
Bob goes on to download 12 blocks from Alice and 12 from Alice.
At the same time, Alice downloads 12 blocks from Bob and 12 from the server.
When Charles joins, he downloads 14 blocks from Alice, 14 from Bob, and 14 from the server.
See? If you assume start times are separated by at least one block, it doesn't matter that you can't download block Q from Alice before Alice finishes downloading it. You download it from Bob, Charles, or the server, or you download a different block.
The net upload capacity of a Torrent is equal to the net upload capacity of clients that have downloaded one block. The net upload capacity of konspire networks is equal to the net upload capacity of clients that have received a complete upload.
Bandwidth disparities are a separate problem. With Bittorrent, everyone's upload and download capacities are used to the max. With konspire, it's possible to have a T1 download from a 14.4, while another T1 uploads to a 14.4. This problem could be reduced by dividing files into --wait for it-- blocks and allowing --wait for it -- all clients to use all servers.
Konspire is a neat idea, but I don't think it's technologically superior to a cron job that runs this:
killall btdownloadheadless; btdownloadheadless --url http://example.com/latesttorrent.bt