Slashdot Mirror
P2P Content Delivery for Open Source
Orasis writes "The Open Content Network is a collaborative effort to help deliver open source, public domain, and Creative Commons-licensed content using peer-to-peer technology. The network is essentially a huge 'virtual web server' that links together thousands of computers for the purpose of helping out over-burdened/slashdotted web sites. Any existing mirror or web site can easily join the OCN by tweaking the HTML on their site."
Can you hide your IP?
That's the only thing that matters!
It's Christmas everyday with BitTorrent.
What we need is some gateway product to get young kids hooked on programming.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
I see a slight problem, depending on how CAW is implemented.
Scenario #1:
Assuming the Originator Apache responds with HTTP headers such as those in CAW to advertise site-wide mirrors like this:
X-URI-RES: http://urnresolver.com/uri-res/N2L?urn:sha1:; N2L
When the originator Apache site updates any documents, the URN resolver (or mirror) will silently fail without realizing which document has been updated. It would need to rescan the entire website, even when only one document has changed.
Scenario #2:
The opposite problem occurs with the Originator Apache responding with HTTP headers such as this:
X-URI-RES: http://untrustedmirror.com/pub/file.zip; N2R
The mirror will respond successfully, but will give an out-of-date version of the file without the client or the mirror realizing it. The mirror would then have to manually scan the website on a regular basis (even when nothing has changed) to prevent anything getting too out of date.
Scenario #3 (Solution):
However, if the Originator Apache responds with HTTP headers such as this:
X-URI-RES: http://untrustedmirror.com/pub/file-mirrors.list; N2Ls; urn:sha1
When the URN resolver or Mirror sees the SHA-1 hash mismatch, it knows which document needs to be updated, and can respond by doing so for just that document.
I realize that CAW is mainly designed with static files in mind (images, PDFs, ISOs) where updates occur rarely (or never). And no, I don't see Apache calculating the SHA-1 for dynamic pages like Slashdot anytime soon. However, updates do occur to images, PDFs, ISOs, etc. on occasion. I do think CAW(#3) could be used (and useful) for large, heavily subscribed RSS feeds without too much trouble. Maybe elsewhere in dynamic content.
"There's so much left to know/ and I'm on the road to find out." -Cat Stevens
I don't see this helping the slashdot effect. How many people are actually going to download the browser plugins required to make all this work?
I mean, I might get the plugins if I'm dealing a lot with sites that use this technology, but how many people will be dealing with a lot of these?
And those sites are using this, are probably the ones that are use to high volumes of traffic, so they prepare for it. The average site that can't handle a slashdot, can't handle it because they generally don't need to.
How would something like this work? Presumably slashdot would have to link to a single site, which then farmed out the requests to participants? If this is the case, there is still a single point of faliure, right? And presumably browsers need to know that they are being redirected so any subsequent requests. Thus, how is this more powerful than an (albeit intelligent) javascipt forwarder...? If it's just a simple load baalncing system then I don't see what's so groundbreaking.
Vacancy for signature. Apply within.
If that network don't have any kind of moderation (and as a p2p network, not sure how exactly that can be done right), what will stop people to post or ensure that is not downloading a trojanized versions of programs? Or a new way to distribute viruses, like the ones that are already for kazaa and similars.
indviduals will be able to help distribute free content by donating their spare bandwidth and disk space to the network.
Sarcasm aside, while I can see where they're going with this I can't see it ever seriously taking off. Most of the world are still on 56k (or less) and I know I regularly hunt for things to delete so I can squeeze something else on my hard drive.
...Google's cache!
Any existing mirror or web site can easily join the OCN by tweaking the HTML on their site
Sounds a lot like it to me - especially the bit about it being like a virtual server. I suppose if it stored images and stuff then it's be a bit better, but will it ever match Google's speed and breadth of content?
I surely see some potential in the idea but what about standards. Allthough it's GPL-ed the standards aren't adopted by any organisation like IETF, OASIS or W3C. If one of these organisations would see the potential for this it would make things a lot easier. You would get rid of plug-ins, extentions etc. and all browsers as well as servers would support it.
In fact I'm pretty astonished none of these organisations has ever picked up P2P.
/(bb|[^b]{2})/
It seems like alot of you just read the front page and seem to think this is some type kazaa clone. I agree the browser pug in is kinda gay.
What this "could" mean is say if your favorite distro has just been updated, we all know how hard it is to download 3 isos while they are in high demand. The thing about OCN and OnionNetworks type software is that the high demand and download rate will help the availibility. Plus everything is authenticated and logged so worms/trojens/fakes really arnt a problem.
As far as OCN goes, it's not for warez, and divx. I think it's intended for geek's free software distrobution. So love it, and try to inovate it.
-makoffee
Broadband ISP's in europe impose a maximum limit for traffic per month. How long before versions come out that only download and not upload? What open source needs is a way to make users pay with bandwith. Instead of using paypal, allow a user to pay for his download with X megs of upload capacity. This could lower costs for distro-upgrades considerably.
Also, how is this different from bittorrent?
The OCN does not require data to be encoded and uses standard HTTP for all of its data transfer.
This means that it can download content from a regular Apache web server w/o any modification whatsoever.
This also means that the peers are simply embedded web servers, can stream content (video) straight to the browser, and can use SSL out of the box.