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."
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.
be careful when informing the masses about new technologies, wouldn't want to negate the potentcy of the slashdot effect..
"Life is great; without it, you'd be dead." -Harmony Korine
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
Got a slashdotting and kept on ticking. Surely must be a sign of the apocalypse!
--------
Free your mind.
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?
Eve Fairbanks says I drive a hybrid!LOL
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).
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).
A Blog With Unlimited Bandwidth
Wouldn't that be called the Aquinas Protocol? ;-)
Are you local? There's nothing for you here!
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
If I understand how this works, is there a sci-fi channel that will send me the latest enterprise episodes as they come to hand? what about a simpsons or futurama channel? Are there some examples out there already?
...the previous /. story about konspire:
here it is....
It looks like they've done a lot of work on the project to deserve 2 submissions in 3 weeks.....;o)))
1. No sig. 2. ???? 3. Profit!!!
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"?
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.
Janie took my gun...
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.
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
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
How long until the spammers start sending their crap out on something like this? Since the user cannot select what he is trying to get, it seems like this tool just begs spammers to place fraudulant files on your machine.
User: "Hey, the new White Stripes song!"
Song: "How would you like to increase your penis size by as much as 30%?"
User: "Man, this song sucks!"
[FromTheMorning]
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.
Oh dear, like there isn't enough crap around on the innurnet ...
n telligent-to-say paradigm. Most of them are stupid, some are okay, and a precious few are really worth reading.
Methink someone should create a blog rating server that blog readers could vote in and people could consult before choosing to read a blog. Blogs are very low S/N ratio, simply because they implement the hey-I-can-talk-so-I-will-even-if-I-have-nothing-i
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
My first read of the comparison with BitTorrent just feels wrong. Unfortunately I haven't the time right now to go into it properly (being at work, with boss coming up every five minutes) but does anyone else get the impression that one of the premises (leading him to the conclusion that k2b is more scalable) is wrong?
He says that it's based on most people have far greater download than upload bandwidth, so people lower down the chain are going to receive a trickle. Yet every time I've done a BT download it has maxed out my downstream bandwidth. My first guess is that he doesn't take into account people leaving their BT clients open once they've finished a download.
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
The fact is, it would be a great idea to combine the idea of a secure distribution channel and a swarming distribution mechanism. If the protocol extended to permit a web of trust like PGP, then you could have groups of people who could send files to a secure, very fast, distribution channel.
Now if we could get rid of the BitTorrent need to trust a single host with the task of tracking who has what... then we're there.
--Mike--
The simplified view of BitTorrent that the author proposes supposes that everyone has a DSL line with identical properties. This is a false and misleading assumption. Some lucky users have bad-ass university broadband, other poor bastards are trapped on modems. The randomized, dynamic, slowest uploader dropping behavior of BitTorrent sees to it that fast clients will eventually find each other, while slow clients will be pushed down to others more appropriate to their level, even as speeds change. As far as I can tell, k2b does not appear to have any way to do that, and T1s can end up trapped behind DSL while cable modems end up squandering their speed on phone modems.
Another point I should make is that as BT makes files easy to distribute not only because it spreads the load, but because it virtually eliminates all of the difficulties of setting up and maintaining a server. In many of these swarms, a large percentage of people actually WANT to help spread the file and are willing to serve much more than just their part. Some of them distributed through other more complex means before (irc bots, hotline servers, etc.) but others never went through the trouble. In any case, it makes it easy (and obligatory) to serve, and so these channels have much more serving power than they ever did before.
---If you can't trust a nerd, who can you trust?
1 KByte = 1000 bytes
1 KiByte = 1024 bytes
1 MByte = 1.000.000 bytes
1 MiByte = 1.048.576 bytes
I believe that the analysis of how efficiently BitTorrent works breaks down on two points.
First, it assumes that the BitTorrent clients disconnects immediately after downloading, while the k2b network is constantly connected. Obviously this makes MUCH more bandwidth available to k2b as the same number of people are connected but for longer periods of time. Secondly, it assumes that all clients have the same bandwidth available and that each client can only transmit data to one other client at a time. If BT could only transmit to one client at a time it would definately be hindered, whereas k2b was designed to only transmit to one node at a time.
k2b claims to excel at 'zero-day' distribution and to work well for large-files, but this is exactly when k2b falters. The analysis is based off of 'TimeSteps', which is the amount of time it takes to transfer the complete file. Given that for large files it can take several hours or even days, it may very will take weeks before the 'growth' part of the log2 curve kicks in.
Taking some ideas from k2b, and using it to distributed signed torrent files that would then be launched and automatically killed at some point in time would make this a very very powerful system. What that 'point in time' should be would be a point for experimentation and perhaps be a configuration setting for the channel owner (not the end user). Perhaps the client kills itself 2 hours after its download completes, or at some set time at which distribution is to cease, or even at some function of the filesize or amount of time it took to download the file.
The idea behind k2b is sound, and I do believe that it can succeed with distributing small files.
The only other question I would have regarding such a system is how a disconnected node would be handled. Does it locate another upstream node to look for a place to connect? I'd imagine this all goes into the 'intelligent' tree structure where the faster more permament nodes are near the top while slower nodes that don't have an always-on connection are near the bottom and can still get recent 'broadcasts' even though they were disconnected for a day or so.
In any event, this is something that SHOULD at least be considered. Much of the k2b website is written from a perspective of justifing or defending WHY k2b is superior without taking an honest look at some of its shortcomings.