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."

Comments

So so

[indros]

I tried this a couple of weeks ago.. It's so so, but as a user you didn't really have the ability to get files you want, but what other people want you to get, and it seems very unpredictable as far as start time, length of download, etc. Of course it was still beta so I expect to see improvements yet.

OTOH, it's nice just to sit there and let the pr0n roll in.

Re:So so

[Sparr0]

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.

Re:So so

[greenalbatros]

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


as the man said: porn porn porn porn porn....

blogtorrent?

[sweeney37]

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

Damn

[Gortbusters.org]

Got a slashdotting and kept on ticking. Surely must be a sign of the apocalypse!

Huh?

[GMontag]

essentially turns the standard p2p model upside down

I thought b2b was already old hat?

Oh, completely upside down? b5b, yep that is new but what the heck does it mean?

Web Based Interface

[mistermund]

The web based interface is refresing.

That's one of the biggest strengths that Audiogalaxy had (before the service got defanged). You could run their Linux client on a box at home, then sign into the Audiogalaxy site from anywhere (work, school, etc) and grab different things. Made it easy to run the client somewhere safe, with a fast connection, or lots of drive space, and get to it from anywhere. Nice to see another app taking the same approach (though you host the web interface yourself).

Re:Web Based Interface

[dew-genen-ny]

Try MLDonkey

It is a cross p2p network client, capable of connecting to eDonkey/Overnet, Gnutella, Fasttrak, Shareaza, and a whole host of others. It's also a fairly decent BitTorrent client.

It has a very nice html interface, and that is a major bonus, since you can also then set it up so that you can start new files downloading at home, while you're at work (but be careful folks, make sure you've got your setup pretty tight, or I'm sure you'll have script kiddies downloading hardcore pRon for you all night long)

Really can't recommend it enough.

Works nicely

[Eloquence]

I've been running K2B for the last few days and it's quite impressive (the web-UI could still use some polishing, though). You can choose from several channels to subscribe to, such as "mp3jackpot", and automatically get the latest files broadcast in these channels while your node is running. At this time there are actually no illegal channels, at least I've seen none; the mp3jackpot channel above is run by mp34u, a site where music fans choose and rate freely available songs. Some of them are actually pretty good, and it's about time the net is used more effectively to promote the free music that's floating around.

There's even a channel called "publicdomain4u" which broadcasts very old music from the 1920s and 1930s. If you have something to say, you may consider setting up your own channel on k2b and use it to broadcast text files, music, videos etc. It is possible to share the private key to your channel so you can collaborate with others to broadcast files in it. I for one will be keeping an eye on the new channels that pop up. For those running other p2p clients: K2B doesn't normally take much bandwidth, you can use it in parallel.

P2P broadcasting may very well be the next important development. It's a bit like Usenet, but fully decentralized, and with some quality control (K2B has recommendation channels, and only users who own the channel private key can broadcast files in it, eliminating the spam problem).

Might this

[Anonymous Coward]

Finally be an effective distribution mechanism for the hundreds-of-small-files model that would be needed for among other things, say, p2p mirroring of webpages (html and image files) that Bram Cohen says has been so problematic?

At the least, couldn't, say, Keenspace save almost all of their bandwidth by use of this protocol, having people subscribe to channels for the webcomics they read daily and just releasing a new comic on the channel every day?

ANyway, questions i can't seem to work out from this page: 1) Does this have one big gnutella-like mesh, or does it follow BitTorrent's create-a-new-p2p-network-for-each-torrent file model? 2) Is the idea that you set up your "channel" to contain certain files, and anyone who's ever had that exact file anywhere on the Konspire network can download this file to you, or is it again like BitTorrent and if two different channels happen to share one file in common, the subscribers to each channel will be unable to use members of the other channel as mirrors?

If the former in each of the two questions above, this is the ULTIMATE rom distribution mechanism, and i eagerly look forward to using it for that purpose :)

Anyway this is neat to see, and good to see something like this done right. And wierdly enough, I actually expect this to be of much use to me in a totally legal fashion (the website my non-AC persona runs will soon be adding a regularly updated feature which i was expecting to be a major bandwidth drain, but which this Konspire thingy seems more or less just tailor-made for...)

- super ugly ultraman

So if you don't swarm...?

[Anonymous Coward]

Something I am looking at this and trying to figure out but don't see elucidated: If you don't "swarm", how do you deal with one single host crapping out?

I.E., let's say I'm downloading this 3 MB file from this one guy, and halfway through he disconnects. I'm left with half a file. What happens then?

My bigger worry: let's say that the app does support file resume, so my host disconnecting is not a worry. But what happens if I set a channel to run and leave the room, and suddenly the download rate for the host my client has chosen drops to 0.1k/sec. How does the app handle that? If I constantly watch the download i could click "retry download with different host", but if I'm going to have to watch my downloads constantly and reset them every time they start sucking then they've lost their one benefit over kazaa. How does this app ensure that optimal download speeds are had by all, and does it at least have a feature where i can say "if the download ever goes below 0.5k/sec, try to find a new source"?

Old hat stuff

[Zeddicus_Z]

Push technology pushing multimedia content. Meh, it was a bad idea 4 years ago when they first tried it with normal Web content. Why would anyone thing that using bandwidth-hungry archives/multimedia/whatever is going to make Push suddenly a sucessful content. Speaking even in the simplest terms of ISP data charges, people go looking for what they want (music/movies/etc), then pay for it (fees to ISP for data Xfer). 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.

Hmmm

[Xentax]

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

it depends on the axis of the turn

[DrSkwid]

if the axis of rotation was the x (horizontal) axis then indeed it would be

d5d

however if the axis of rotation was either of the remaing axes then the result would be

b5b

Re:it depends on the axis of the turn

[jtosburn]

We need to work on our visualization skills; on /. there will always be a pedant to "help". In this case it's me.

If our axes are:

y
|
|
|
L________ x
/
/
/
z

Then rotating b2b around:

X --> 959, or q5q depending on if you're retaining relative position of the characters

Y --> d5d

Z --> 959, or q5q, once again depending on whether or not you're retaining relative position.

We'll skip the possible iterations of mirroring this time around ;)

Bad BitTorrent analysis

[Anonymous Coward]

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.

Re:BitTorrent analysis - is it crap?

[Webmonger]

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