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."
on your blog, you might have a "picture of the day". On your konspire2b channel, you can have a "movie trailer of the day" or even a "gnu/linux distribution of the day". Bandwidth limitations are essentially taken out of the equation.
as intriguing as this idea is, couldn't you set a torrent up to do the same thing?
Mike
The point here is that this is designed for situations where tens of thousands of people all want the same content at the same time.
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.
>People wont pay for a lot of crap they dont want in
>any way on the off chance they may receive that
>which they do.
Then how do you explain cable tv?
I've read his analysis of Konspire[2b] vs BitTorrent, and the description of BitTorrent is wrong.
The main point he missed is that BitTorrent does not request (and thus serve) pieces in order. See the bit torrent protocol description, and search for "Downloaders generally download pieces in random order, which does a reasonably good job of keeping them from having a strict subset or superset of the pieces of any of their peers."
Thus BitTorrent does not have the cascading limitation he describes, quite the contrary: if a three-piece download is downloaded by three persons, there is a good likelyhood. That they will not get the same piece and will thus be able to exchange the pieces later on.
What's more, the situation where the number of downloaders is equal to the number of pieces is the worst-case. Less downloaders reduce the chances that they are downloading the same piece, more increases the availability of each piece.
I have not calculated the resulting scalability, but it should be the same as konspire[2b].
There is more. I have not read the protocol description of konspire[2b], but from the description given in the comparison, it seems to transfer complete files between nodes. So there is no incentive to stay connected to serve other. In BitTorrent, the fact that each downloaders receives potentially different pieces means that on average, each will be able to at least partially serve new comers.
Basically, they've reinvented netnews(usenet) without the benifits of savings to the ISP and a multi-tier network.
Every ISP I've had I would consider clueful has offered good netnews service, because it lets people download these kind of things without stressing their bandwith too much, IE they download it once, their customer can all download it from the internal network. The ISP becomes a file caching ultrapeer.
Since some of the large providers these days don't provide netnews (Comcast bought out AT&T Broadband who did have netnews, and Comcast doesn't.. Sigh. I'll miss it.) this could still be quite useful.
Blessed are the pessimists, for they have made backups.
Here what I don't understand:
How does it solve the main P2P problem of leechers?
This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
2. go to bed
I guess that since content distribution is automatic you'd have to never use K2b ever again, or delete the file or something to stop distribution. You'd have to be pretty mean to do that. Meanwhile alice has heard from the bob's who subscribe to her channel that they haven't got theGrid.mpg, so she chooses one of them to be node 1
___________________________
the Spiders are coming
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
It took me several minutes of surfing to figure out that your client is for the windows platform. Perhaps you could state that clearly, upfront?
Just a suggestion.