The solution is simple. Any intelligent company entering into a software license agreement should make sure that they have a source code escrow agreement in case the vendor goes belly up.
This practice is becoming very standard nowadays and completely fixes this problem.
The Tornado client for the Open Content Network has support for P2P download channels based on RSS.
Basically, you click on a link which will subscribe the peer to the channel, and the peer will automatically download/pre-cache any new items that are added to the RSS feed.
You simply have to create an RSS feed and create a link that converts that feed into a channel that is subscribable via the Open Content Network.
I've set up an example of a movie trailer RSS feed here And have linked it into the Open Content Network here.
I run a software company called Onion Networks that provides peer-to-peer content delivery technology to movie studios building VOD systems.
With fast P2P content delivery technology, MPEG-4 compression, and PVR-like time shifting devices - the speed, storage, and economics are there today to provide DVD-quality VOD.
The only problem is that it is taking the studios a long time to roll out there VOD solutions, but trust me, they'll be upon us in the near future.
For more information on the protocols that underly these P2P content delivery systems, please check out the Open Content Network Specs
Since proper attribution is usually appreciated, people should know that the Forward Error Correction (FEC) library comes from Onion Networks' FEC library that they developed for Swarmcast.
The most up to date version of the Java FEC library can be found here.
While the OCN does not make it easy to discover what other users are downloading, it is not anonymous like Freenet.
However, the problem with systems like Freenet is that the latency is incredibly high and has no way to leverage the existing mirrors that host much of the open source content today.
Since the OCN is built around HTTP, it can start its downloads immediately from the network of mirrors and as peers are discovered, it moves more of the burden onto the peers.
The end result is that the OCN has about the same latency as normal web browser, but can provide very fast parallel downloads when leveraging existing mirrors.
That said, if high latency isn't a problem, then we highly recommend using Freenet. We think its a great project and look forward seeing more and more applications built on top of it.
This is really good feedback Adam. We'll definately need to add this type of explanation to the pop-up page and maybe expand upon some things in the FAQ.
We should also probably explicitly state that absoutely no adware/spyware/shitware will be installed on your machine.
The primary purpose of the OCN is to promote public domain, open source, and Creative Commons-licensed content.
It has been intentionally made very easy to incorporate new clients into the OCN. All you need to do is make an XML-RPC call advertising the content you have available and you're in.
If Bittorrent joined the OCN, it could leverage the resources of other clients in the network and give more choice to users about which software they want to use.
The eventual goal is to get this type of technology integrated directly into Mozilla, Squid, and Apache. But that will probably take some time...
The newly relaunched Happy Puppy uses the Tornado Cache Plug-in to provide some pretty fast downloads. If you're interested in seeing this stuff in action I recommend checking out the site.
That said, the OCN is open to any and all applications out there, so I'd encourage them to join the OCN.
While these are insightful points, these are not a problem because the OCN obeys HTTP caching semantics. Thus, just like your browser cache, it can deliver stale content within a certain amount of time before the OCN refreshes its cached copy.
To get a better picture of how HTTP caching semantics work, I recommend trying out Cacheability Engine and enter in a couple of sites to see how cacheable their content is.
Also, the OCN uses the SHA-1 hashes for all content addressing as soon as it translates the URL to the SHA-1 URN. There-after, the content is only referred to by its SHA-1 URN, so there is no concern about version conflicts between mirrors/peers, because a single SHA-1 URN can only ever point to a single version.
Your point re: dynamic data is a good one. The OCN really isn't designed for delivering dynamic content because it changes too frequently and the cached copies on the peers would quickly become stale. However, we are doing some work with caching RSS feeds, which provides a nice trade-off between dynamic and static content.
The crew at the Open Content Network have released a specification for serializing hash trees. The specification is called the Tree Hash EXchange (THEX) and is being implmented in both the Open Content Network and Gnutella. Furthermore, this specification is compatible with the TigerTree hashes used for Bitzi.
We wrote an optimized Reed-Solomon library for Swarmcast that can do up to 65k shares. Its available under a BSD-style license. Also, since Swarmcast is a P2P content delivery system, the library also supports cryptographic integrity checking, so you can ensure that everything is in tact.
Unfortunately the Swarmcast project has languished after 1.0, but we have started a new project called the "Open Content Network"
The OCN provides an important piece of the puzzle with its metadata proxy servers. These servers automatically generate the verification information (SHA-1 hashes) necessary to perform secure P2P downloads.
It would be nice if this project leveraged the significant amount of work going into the OCN to provide a standard way to securely delivery any open source content across peer-to-peer networks.
Our initial approach is actually much simpler. We will simply certify a number of domains that are trusted to host mostly open source content, such as kernel.org, debian.org, etc, and use a network of metadata proxies that extract the secure hash information for file verification. Idealy each of the sites will run their own meta-data proxy so that the secure hash information is trustworthy.
The Content-Addressable Web provides HTTP extensions that solve many of the problems associated with distributing content across ad hoc networks. This is because the addressing of the system is location-independant and content-centric. This makes it perfect for unreliable and transient wireless networks.
If code is in the public domain anyone is free to do whatever they want with it. Therefore it is by definition Open Source. I'm sure if you check out the OSD on opensource.org it will include Public Domain.
It would be really cool if the Redhat Network supported the Content-Addressable Web so that we could automatically download our ISOs from the closests avaliable mirrors, and even download from multiple mirrors in parallel.
Stay tuned for the O'Reilly Emerging Technology Conference where we will be unveiling a companion set of technologies to the CAW that will change distribution of open source content forever!
If anyone wants to know more about CAW before the conference, please contact me at justin_at_onionnetworks_dot_com
We did a significant amount of work in this vein with Swarmcast and have been building a lot of the (rather complex) technology necessary for Reliable Multicast
Multicast is not panacea though, because it is not very widely deployed on the Internet, and since there is no caching in Multicast, all of the receivers must be downloading near the same time to realize the bandwidth savings...So in many ways P2P caching has advantages over multicast, which is why we do both.
--
Justin Chapweske, Onion Networks
Jibe has a wonderful product for enterprise file and data sharing and I think is making some good progress and will be quite successful.
My employer, Onion Networks, is focused on building enterprise content delivery solutions using P2P. 2002 is off to a great start for us as companies are immediately seeing the value of P2P for cutting costs and increasing reliability within their networks.
Slashdot Mirror
The solution is simple. Any intelligent company entering into a software license agreement should make sure that they have a source code escrow agreement in case the vendor goes belly up.
This practice is becoming very standard nowadays and completely fixes this problem.
I think you've just described every Freshman Computer Science student that I've ever met.
Sorry guys, but the size of your dick isn't measured by how many IRC factoids you can spew out.
Works for me:
here
No, the old IO apis were not re-written to run on top of NIO. NIO is a whole new can of worms/bugs to be ironed out.
Basically, you click on a link which will subscribe the peer to the channel, and the peer will automatically download/pre-cache any new items that are added to the RSS feed.
You simply have to create an RSS feed and create a link that converts that feed into a channel that is subscribable via the Open Content Network. I've set up an example of a movie trailer RSS feed here And have linked it into the Open Content Network here.
I run a software company called Onion Networks that provides peer-to-peer content delivery technology to movie studios building VOD systems.
With fast P2P content delivery technology, MPEG-4 compression, and PVR-like time shifting devices - the speed, storage, and economics are there today to provide DVD-quality VOD.
The only problem is that it is taking the studios a long time to roll out there VOD solutions, but trust me, they'll be upon us in the near future.
For more information on the protocols that underly these P2P content delivery systems, please check out the Open Content Network Specs
The most up to date version of the Java FEC library can be found here.
The Internet Archive currently uses it for distributing live concert recordings, so it should work great for video too.
They have commercially licensed the Tornado CDN software.
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.
While the OCN does not make it easy to discover what other users are downloading, it is not anonymous like Freenet.
However, the problem with systems like Freenet is that the latency is incredibly high and has no way to leverage the existing mirrors that host much of the open source content today.
Since the OCN is built around HTTP, it can start its downloads immediately from the network of mirrors and as peers are discovered, it moves more of the burden onto the peers.
The end result is that the OCN has about the same latency as normal web browser, but can provide very fast parallel downloads when leveraging existing mirrors.
That said, if high latency isn't a problem, then we highly recommend using Freenet. We think its a great project and look forward seeing more and more applications built on top of it.
This is really good feedback Adam. We'll definately need to add this type of explanation to the pop-up page and maybe expand upon some things in the FAQ.
We should also probably explicitly state that absoutely no adware/spyware/shitware will be installed on your machine.
The primary purpose of the OCN is to promote public domain, open source, and Creative Commons-licensed content.
It has been intentionally made very easy to incorporate new clients into the OCN. All you need to do is make an XML-RPC call advertising the content you have available and you're in.
If Bittorrent joined the OCN, it could leverage the resources of other clients in the network and give more choice to users about which software they want to use.
The eventual goal is to get this type of technology integrated directly into Mozilla, Squid, and Apache. But that will probably take some time...
The newly relaunched Happy Puppy uses the Tornado Cache Plug-in to provide some pretty fast downloads. If you're interested in seeing this stuff in action I recommend checking out the site.
That said, the OCN is open to any and all applications out there, so I'd encourage them to join the OCN.
While these are insightful points, these are not a problem because the OCN obeys HTTP caching semantics. Thus, just like your browser cache, it can deliver stale content within a certain amount of time before the OCN refreshes its cached copy.
To get a better picture of how HTTP caching semantics work, I recommend trying out Cacheability Engine and enter in a couple of sites to see how cacheable their content is.
Also, the OCN uses the SHA-1 hashes for all content addressing as soon as it translates the URL to the SHA-1 URN. There-after, the content is only referred to by its SHA-1 URN, so there is no concern about version conflicts between mirrors/peers, because a single SHA-1 URN can only ever point to a single version.
Your point re: dynamic data is a good one. The OCN really isn't designed for delivering dynamic content because it changes too frequently and the cached copies on the peers would quickly become stale. However, we are doing some work with caching RSS feeds, which provides a nice trade-off between dynamic and static content.
The crew at the Open Content Network have released a specification for serializing hash trees. The specification is called the Tree Hash EXchange (THEX) and is being implmented in both the Open Content Network and Gnutella. Furthermore, this specification is compatible with the TigerTree hashes used for Bitzi.
We wrote an optimized Reed-Solomon library for Swarmcast that can do up to 65k shares. Its available under a BSD-style license. Also, since Swarmcast is a P2P content delivery system, the library also supports cryptographic integrity checking, so you can ensure that everything is in tact.
Unfortunately the Swarmcast project has languished after 1.0, but we have started a new project called the "Open Content Network"
Another complementary project in progress is the Open Content Network
The OCN provides an important piece of the puzzle with its metadata proxy servers. These servers automatically generate the verification information (SHA-1 hashes) necessary to perform secure P2P downloads.
It would be nice if this project leveraged the significant amount of work going into the OCN to provide a standard way to securely delivery any open source content across peer-to-peer networks.
Check out the OCN specifications here.
Our initial approach is actually much simpler. We will simply certify a number of domains that are trusted to host mostly open source content, such as kernel.org, debian.org, etc, and use a network of metadata proxies that extract the secure hash information for file verification. Idealy each of the sites will run their own meta-data proxy so that the secure hash information is trustworthy.
The Content-Addressable Web provides HTTP extensions that solve many of the problems associated with distributing content across ad hoc networks. This is because the addressing of the system is location-independant and content-centric. This makes it perfect for unreliable and transient wireless networks.
--
Justin Chapweske, Onion Networks
If code is in the public domain anyone is free to do whatever they want with it. Therefore it is by definition Open Source. I'm sure if you check out the OSD on opensource.org it will include Public Domain.
--
Justin Chapweske, Onion Networks
It would be really cool if the Redhat Network supported the Content-Addressable Web so that we could automatically download our ISOs from the closests avaliable mirrors, and even download from multiple mirrors in parallel.
Stay tuned for the O'Reilly Emerging Technology Conference where we will be unveiling a companion set of technologies to the CAW that will change distribution of open source content forever!
If anyone wants to know more about CAW before the conference, please contact me at justin_at_onionnetworks_dot_com
--
Justin Chapweske, Onion Networks
We're working on it, something will probably be ready in time for the O'Reilly Emerging Technologies conference.
--
Justin Chapweske, Onion Networks
We did a significant amount of work in this vein with Swarmcast and have been building a lot of the (rather complex) technology necessary for Reliable Multicast
Multicast is not panacea though, because it is not very widely deployed on the Internet, and since there is no caching in Multicast, all of the receivers must be downloading near the same time to realize the bandwidth savings...So in many ways P2P caching has advantages over multicast, which is why we do both.
--
Justin Chapweske, Onion Networks
Jibe has a wonderful product for enterprise file and data sharing and I think is making some good progress and will be quite successful.
My employer, Onion Networks, is focused on building enterprise content delivery solutions using P2P. 2002 is off to a great start for us as companies are immediately seeing the value of P2P for cutting costs and increasing reliability within their networks.
--
Justin Chapweske, Onion Networks