Slashdot Mirror
Open Content Network (P2P meets Open Source)
Orasis writes "The creators of Swarmcast have announced a new peer-to-peer content delivery network called the Open Content Network. The OCN will allow users to download open source and public domain content from multiple peers and mirrors in parallel. The system is designed to augment the existing mirrors with bandwidth from the p2p network and should eliminate the "Slashdot Effect" for popular open source content."
The Open Content site just announces a list of intentions. Anyone can put this kind of info up. It looks to me like nothing has been achieved yet, making this not really news.
---- scrm
A secure system for validation and verification of downloads will obviously need to be implemented. Imagine all of the fun things someone could do if they, say, inserted a rogue module into the linux kernel code. Or the latest release of samba, gtk, glibc, Mozilla, ssh, openssl... the list goes on and on.
-- Minds are like parachutes... they work best when open.
Perhaps this is a silly question, but I worried about it with Napster and subsequent file sharing software, too. Is is possible to contribute and be secure?
Can I bum a sig?
Maybe it's just me, but this makes me a little nervous that when the "Open Content Network" gets too popular and dragged down in litigation, the "Open Source" folks are going to find themselves tarred with the same brush; guilty by association. Not what's needed at this juncture.
It's supposed to be completely automatic, but actually you have to press this button.
What about the openft protocol, they've been working on that for a while gift.sourceforge.net. They originally used the fasttrack protocol (KaZaa), but after kaZaa changed there specs, they decided to create their own protocol.
Sounds good. Maybe they can team up with the kind of artists who are currently promoting their music on MP3.com
(I just bought a couple of CDs from a band who make all their music available for free download, so it must work!)
Would it make much difference for software apps? They're mostly mirrored anyway, and Mozilla/OpenOffice-style distribution doesn't seem to be suffering many bandwidth problems.
...longbeards can remember the "good ole days" where the free flow of ideas and not making money were what made the pre-commodity internet a very worthwhile place to be. Everyone was expected to contribute their resources for the benefit of all, and none of it was (apparently) designed to make help smartass b-school dropout come up with enough cash to buy a 4,000 square foot "bungalo" in Palo Alto.
Count me in.
it gets slashdotted, which would be truely ironic:
What is the Open Content Network? We are in the process of creating the Open Content Network, which aims to be the world's largest content delivery network (CDN).
Users will soon be able to download open source and public domain software, movies, and music at incredibly fast speeds from this global, distributed network.
Using a new Peer-to-Peer technology, called the "Content-Addressable Web", indviduals will be able to contribute to the open source movement by donating their spare bandwidth and disk space to the network.
btw, note how the "implementations" section is not active yet.
"...download open source and public domain content from multiple peers and mirrors in parallel."
These usefull features have already been implemented in KaZaA [www.kazaa.com].
- learn mathematics - shoot dope -
I'm fully expecting that if we ever reach a point where a substantial percentage of users' traffic becomes outbound traffic, the cablemodem and DSL providers are going to start to rethink the current pricing and service packages.
How long before we find ourselves NATted away, able to originate connections only? A few cablemodem providers have already done this to reduce the traffic from file sharing and to knock out code red and other such silliness. And each time a major ISP does this, it leaves a slightly smaller number of other ISPs providing the outbound service, causing the traffic on the holdout systems to rise.
At some point it's going to snowball, and most of us are going to find ourselves NATted away, with only those paying premium prices for real IP addresses getting the priviledge of having their uplink monopolized by strangers.
Says the RIAA: When you EQ, you're stealing bass!
"The system is designed to augment the existing mirrors with bandwidth from the p2p network and should eliminate the "Slashdot Effect" for popular open source content."
:-)
Hopefully you can configure the # of connections, otherwise we will finally be able to get slashdotted from the comfort of our own homes
The problem being that people are bastards.
Why is this a problem? Well, what's to stop an ignorant or malicious individual wrapping up some content with an CC complaint license and injecting it into OCR?
I'm thinking of:
Why would anyone do this last one? Pure malice, to open OCN up to DMCA attack, simply because people (as I said) are bastards, and can't be trusted to behave in a rational civilised fashion. OCN will be a trusted network, and that leaves it open to abuse. I really hope that an actual trustable human will vet everything injected into it.
If you were blocking sigs, you wouldn't have to read this.
Recently some Mame devs (www.mame.net) have been working on some Cojag drivers(cojag is an atari arcade system that uses harddrives - Area51 is a cojag game).
Someone made compressed harddrive images that mame will eventually require. Dispite compression, two of the images were half a gig and one was a gigabyte. The guy who was distributing these files used swarmcast to prevent getting swamped.
It worked pretty well in that tons of people were able to download those huge files without killing servers. However, swarmcast is new enough that swarmcast itself had some server problems. The server had to use an older version of swarmcast to be stable. That pretty much fixed the problem. It used to be that just hoasting ~40meg neogeo roms was nearly impossible, now it is possable to host half-gig files.
"Never, never suspect the dreams within the dreams of dreaming children." ~The Amazon Quartet
Fools, little do they realize the powers they are dealing with!
Okay, I'm sure I'm with the rest of the slashdot communisty when I say that my first reaction was "wow, awesome, score another 3 points for Open Source and freedom."
But I've reconsidered. Before you mod me down, please read what I have to say.
Basically, we are talking about P2P filesharing here. Now remember, other P2P services, like Napster, Gnutella, and IRC, were all originally based on good, sound, legal, moral ideals. But in the course of time, they each became corrupt with those who would use the infrastructure for illegal filesharing and copyright infringement.
Now, I don't want to throw the baby out with the proverbial bathwater. And I don't want to get rid of a useful tool because of a potential for abuse, since by that logic we would not have silverware, cars, or handguns. But we in the Open Source community need to ask ourselves, is now the time when we want to risk associating Linux, *BSD, and Open Source with illegal activities? Don't we have enough anti-hacker rhetoric to fight against?
We need to pick our battles. This isn't one of them.
Karma: Good (despite my invention of the Karma: sig)
Maybe you didn't notice that these guys are the makers of Swarmcast. Or maybe you posted before figuring out what that meant.
Swarmcast is a (working!) program for parallel p2p file downloading. In other words, the technology IS implimented. They basically are just making a modified program to work with a somewhat different set of files. No biggie.
"Never, never suspect the dreams within the dreams of dreaming children." ~The Amazon Quartet
The good old days really weren't so good. It's kind of funny, though, listening to some so-called old-timers constantly whinging about the commercialization of the 'net. Do they really think the huge advance in capabilities would have come about without the economic incentive? Sure, the early days were inventive. They invented the bricks and mortar of the Internet. But the commerce guys have driven the construction of cathedrals, roads, libraries and schools with those bricks.
You know how Download Accelerator lets you get files faster by downloading different parts of the same file via multiple simultaneous connections. That is what this is about, except the Swarmcast guys have each connection going to a different person rather than tons of connections going to the same server.
"Never, never suspect the dreams within the dreams of dreaming children." ~The Amazon Quartet
If the goal here is really to eliminate the "Slashdot Effect" a much more effective solution would be to set up a network of load-balanced caching proxies on geographically distributed fat pipes.
:)
Some will argue that this is in essence what a P2P network is, but why not do it right, using technology we already have that everyone can use(squid.)
Other users' comments regarding the cumulative effects of NAT on P2P networks are incredibly apropos.
But realistically, theres nothing I love more than when the story submitter posts a link to a Google cached version of the content he's posting. We're an agressive bunch and that calls for aggressive measures
This too shall pass.
In those now famous words, wheres the code?
Im sorry i wish i could say im excited, its certianly a VERY good idea, and noe in desprate need of realising, but untill i see the code, its just more hype.
Certianly be a great way for non coders to contribute though, so many times my linux friends say "oh id love to contribute to open source but i can't code", this would definatly be one way, and one which requires very little effort too.
Microsoft IIS is to webserving as KFC is to healthy eating
The main problem I encounter with p2p networks is that the same file with 2 different names will be considered as 2 different files.
This is why the file sharing system only works well with audio and video files and not software files.
Hence, such an open content network should include an advanced file recognition system with some sort of checksum or whatever : a blend of p2p and mirrors
Violence is the last refuge of the incompetent - Salvor Hardin
Content-Addressable Web
/pub/Redhat-7.1-i386-disc1.iso HTTP/1.1
R ES: http://www.linuxmirrors.com/pub/Redhat-7.1i386-dis c1.iso ; N2R
Content Distribution Networks (CDNs), such as Akamai, have shown that significant improvements can be made in throughput, latency, and scalability when content is distributed throughout the network and delivered from the edge. Likewise, peer-to-peer systems such as Napster and Gnutella have shown that normal desktop PCs can serve up enormous amounts of content with zero administration. And more recently, systems like Swarmcast have been introduced that combine the CDN and peer-to-peer concepts to gain the benefits of both. The goal of the Content-Addressable Web is to enable these advanced content location and distribution services with standard web servers, caches, and browsers.
The main benefits of the Content-Addressable Web are:
Throughput - Browsers will be able to download content from multiple sources in parallel
Bandwidth Savings - Browsers will automatically discover and select the closest mirror for a piece of content.
Fault Tolerance - Even if a site goes down in the middle of a download, browsers will automatically locate another mirror and continue downloading.
Scalability - Any number of machines may be added to the network, creating a CDN ad hoc, with very little administration.
Security - Browsers will be able to safely download content from untrusted mirrors without risk of corruption or viruses.
The full paper describing the "HTTP Extensions for a Content-Addressable Web" is available here.
The goal of the Content-Addressable Web (CAW) is to enable the creation of advanced content location and distribution services over HTTP. The use of content addressing allows advanced caching techniques to be employed, and sets the foundation for creating ad hoc Content Distribution Networks (CDNs). This document specifies HTTP extensions that bridge the current location-based Web with the Content-Addressable Web.
1. Introduction
Content Distribution Networks (CDNs), such as Akamai, have shown that significant improvements can be made in throughput, latency, and scalability when content is distributed throughout the network and delivered from the edge. Likewise, peer-to-peer systems such as Napster and Gnutella have shown that normal desktop PCs can serve up enormous amounts of content with zero administration. And more recently, systems like Swarmcast have been introduced that combine the CDN and peer-to-peer concepts to gain the benefits of both. The goal of the Content-Addressable Web is to enable these advanced content location and distribution services with standard web servers, caches, and browsers.
There are a number of short-comings of current web architecture that the Content-Addressable Web aims to overcome. These include discovering optimal replicas, downloading from untrusted caches, and distributing content across the Transient Web.
1.1 Optimal Replicas
There are currently no mechanisms within HTTP that allows a user-agent to discover an optimal replica for a piece of content. This problem is due to the fact that HTTP caching practice assumes a hierarchical caching structure where each user has a single parent cache. Thus while one can discover an object's source URI from a cached copy, there is no mechanism to discover a list of replica locations from the source. This problem is evidenced by the fact that users must manually select the closest mirrors when downloading from Tucows, FilePlanet, or the various Linux distributions. The CAW solves this problem by providing distributed URI resolvers that user-agents can query to find an optimal replica.
1.2 Untrusted Caches
It is currently unsafe to download web objects from an untrusted cache or mirror because they can modify/corrupt the content at will. This becomes particularly problematic when trying to create public cooperative caching systems. This isn't a problem for private CDNs, like Akamai, where all of their servers are under Akamai's control and are assumed to be secure. But for a public CDN, the goal is to allow user-agents to retrieve content from completely untrusted hosts but be assured that they are receiving the content intact. The CAW solves this problem by using content addressing that includes integrity checking information.
1.3 Transient Web
The Transient Web is a relatively new phenomenon that is growing in size and importance. It is embodied by peer-to-peer systems such as Gnutella, and is characterized by unreliable hosts with rapidly changing locations and content. These characteristics make location-based addresses within the Transient Web quite brittle. Even if traditional HTTP caching was widely leveraged within the Transient Web, the situation wouldn't be helped much. This is because a single piece of content will often be available under many different URIs, which creates disjoint and inefficient caching hierarchies.
This multiplicity of URIs occurs for a couple of reasons:
The original source for a piece of content will often cease to exist or the source's URI will change.
Multiple independent sources often introduce the same content into the network.
Most applications and file manipulation tools will tend to "forget" the source URI of a piece of content.
This URI multiplicity can also occur in the normal web, although it is RECOMMENDED that caching semantics be used when an authoritative source is known. The CAW solves the above problems by providing content-specific URIs that are location-independent and can be independently generated by any host. Additionally, various URI resolution services work in coordination to resolve issues associated with having multiple URIs for a web object.
2. Scope
The HTTP extensions for CAW are intended to be used for in the above scenarios where HTTP is currently lacking. This technology is focused on mostly static content that can benefit from advanced content distribution services. The extensions are intended to be hidden under the hood of web servers, caches, and browsers and should change nothing as far as end users are concerned. So even though a new URN scheme is introduced, there are very few situations where a human will ever interact with those URNs.
One of the more interesting applications of the Content-Addressable Web is the creation of ad hoc Content Distribution Networks. In such networks, receivers can crawl across the network, searching for optimal replicas, and then downloading content from multiple replicas in parallel. After a host has downloaded the content, it then advertises itself as a replica, automatically becoming a part of the CDN.
3. Content Addressing
This specification introduces a URI scheme with many interesting capabilities for solving the problems discussed earlier. A particularly useful class of URI schemes are "Self-Verifiable URIs". These are URIs with which the URI itself can be used to verify that the content has been received intact. We also want URIs that are content-specific and can be independently generated by any host with the content. Finally, to show the intent that these addresses are location-independent, a URN scheme will be used.
Cryptographic hashes of the content provide the capabilities that we are looking for. For example we can take the SHA-1 hash of a piece of content and then encode it using Base32 to provide the following URN.
urn:sha1:RMUVHIRSGUU3VU7FJWRAKW3YWG2S2RFB
Implementations MUST support SHA-1 URNs at minimum.([footnote] A future version of this document will also specify a URN format for performing streaming and random-access verification using Merkle Hash Trees.)
Receivers MUST verify self-verifiable URIs if any part of the content is retrieved from a potentially untrusted source.
4. HTTP Extensions
In order to provide a bridge between the location-based Web and the Content-Addressable Web, a few HTTP extensions must be introduced. The nature of these extensions is that they need not be widely deployed in order to be useful. They are specifically designed to allow for proxying for hosts that are not CAW-aware.
The following HTTP extensions are based off of the conventions defined in RFC 2169. It is RECOMMENDED that implementers of this specification also implement RFC 2169.
The HTTP headers defined in this specification are all response headers. No additional request headers are specified by this document.
It is RECOMMENDED that implementers of this specification use an HTTP/1.1 implementation compliant with RFC 2616.
4.1 X-Content-URN
The X-Content-URN entity-header field provides one or more URNs that uniquely identify the entity-body. The URN is based on the content of the entity-body and any content-coding that has been applied, but not including any transfer-encoding applied to the message-body. For example:
X-Content-URN: urn:sha1:RMUVHIRSGUU3VU7FJWRAKW3YWG2S2RFB
4.2 X-URI-RES
The X-URI-RES header is based off of conventions defined in RFC 2169 and provides a number of flexible URI resolution services. These headers provide various ways of locating other content replicas, including additional sources for a multiple-source download. One can also build an application that crawls across the resolution services searching for an optimal replica. Many other uses can be imagined beyond those given in this specification. The general form of the header is as follows:
X-URI-RES: ; [; target uri]
The service URI specifies the URI of the resolution service. It is not necessary for the service URI to conform to "/uri-res/ ?" convention specified in RFC 2169.
The service type identifies what type of resolution is being performed and how to interpret the results from the service URI. The types are those defined in RFC 2169 and include "N2L", "N2Ls", "N2R", "N2Rs", "N2C", "N2Cs", "N2Ns", "L2Ns", "L2Ls", and "L2C".
The target URI is the URI upon which the resolution service will be performed. The target URI can be any URI and is specifically not limited to the URI specified by the X-Content-URN header. If there is only a single X-Content-URN value, the target URI can be left off to imply that the X-Content-URN value is to be resolved.
It is RECOMMENDED that receivers assume that the URI resolver services are potentially untrusted and should verify all content retrieved using a resolver's services.
It is believed that N2R, N2L, and N2Ls will be the most useful services for the Content-Addressable Web, so we will cover examples of those explicitly.
4.3 N2R
The N2R URIs directly specify mirrors for the content addressed by the URN and can be useful for multi-source downloads. For example:
X-URI-RES: http://urnresolver.com/uri-res/N2R?urn:sha1:; N2R
or
X-URI-RES: http://untrustedmirror.com/pub/file.zip; N2R
The key difference between these headers and something like the Location header is that the URIs specified by this header should be assumed to be untrusted.
4.4 N2L and N2Ls
These headers are used when other hosts provide URLs where the content is mirrored. This is most useful in ad hoc CDNs where mirrors may maintain lists of other mirrors. Browsers can simply crawl across the networks, recursively dereferencing N2L(s). For example:
X-URI-RES: http://urnresolver.com/uri-res/N2L?urn:sha1:; N2L
and
X-URI-RES: http://untrustedmirror.com/pub/file-mirrors.list; N2Ls; urn:sha1
For the N2Ls service, it is RECOMMENDED that the result conform to the text/uri-list media type specified in RFC 2169.
4.5 Proxies and Redirectors
It is useful to allow CAW-aware proxies that provide content-addressing information without modifying the original web server. This allows CAW-aware user-agents to take advantage of the headers, while simply redirecting user-agents that don't understand the Content-Addressable Web. It would be inappropriate to return an X-Content-URN header during a redirect, because HTTP 3xx responses often still include a message-body that explains that a redirect is taking place. Instead it is preferred to return a result of the text/uri-list media type that includes one or more URNs that would normally reside in the X-Content-URN header.
4.6 Example Application
The above HTTP extensions are deceptively simple and it may not be readily apparent how powerful they are. We will discuss an example application that will take advantage of a few of the features provided by the extensions.
In this example we will will look at how the CAW could help at linuxiso.org where ISO CD-ROM images of the various linux distributions are kept. The first step will be to issue a GET request for the content:
GET
Host: www.linuxiso.org
The abbreviated response:
HTTP/1.1 200 OK
Content-Type: Application/octet-stream
Content-Length: 662072345
X-Content-URN: urn:sha1:RMUVHIRSGUU3VU7FJWRAKW3YWG2S2RFB
X-URI-
X-URI-RES: http://123.24.24.21:8080/uri-res/N2R?urn:sha1:; N2R
X-URI-RES: http://123.24.24.21:8080/uri-res/N2Ls?urn:sha1:; N2Ls
With this response, a CAW aware browser can immediately begin downloading the content from www.linuxiso.org, linuxmirrors.com, and 123.24.24.21 all in parallel. At the same time the browser can be dereferencing the N2Ls service at 123.24.24.21 to discover more mirrors for the content.
The existence of the 123...21 host is meant to represent a member of an ad hoc CDN, perhaps the personal computer of a linux advocate that just downloaded the ISO and wants to share their bandwidth with others. By dereferencing the N2Ls, even more ad hoc nodes could be discovered.
4.7 Replica Advertisement
The URI-RES framework provides a significant amount of flexibility in how replica advertisement and discovery can be implemented. One example implementation will be provided in a future specification.
4.8 Acknowldgements
Gordon Mohr (gojomo@bitzi.com), Tony Kimball (alk@pobox.com), Mark Baker (distobj@acm.org)
If my service provider went to NAT's, I would screem at them to upgrade there networks to IPV6 so that they had no excuses to NAT me when IPV6 is commonplace.
thank God the internet isn't a human right.
This is one of those things you hear about that is so simplistic, so necessary, and staring you right in the face, that you stop and say:
"Now, why in the hell didn't I think of that?"
We dance to all the wrong songs.
--Refused.
Content should be signed, and certificates provided by the network.
Signing something says, I have given my permission to.... This places responsibility on someone for any copyright violations.
The network operators can kinda identify who they issued the certificate to.
Digitally signing provides a checksum.
thank God the internet isn't a human right.
i think Windows XP supports IPv6 by default, and windows 2000 supports it.
NAT's also means that you need less global address space, which makes things a bit cheeper to run.
thank God the internet isn't a human right.
I mentioned something like that yesterday
"I would love it if this were completely true, but this merely means this band got 1 sale -- from 1 person"
I like your logic. So obviously the record store is failing when I go in and buy my one CD. From one person. My one CD from one person. To clarify, only one CD from only one person. The record shop is obviously failing.
Yeah right.
No, it means that MP3.com is succeeding, that Aura are succeeding, and that Faithless are shafted (who made the CDs I wanted, but which I'm not gonna buy with the current state of the record industry, and their political representatives)
Here's a hint: when you have lots of people buying one thing each, you make lots of money. Find a maths book. Revise the chapter on multiplication.
Well, for one example, the new RedHat 7.3 .iso files have MD5 sums embedded in them. From the boot prompt, type "linux mediacheck" and it will prompt for a disk to be validated.
A feature to take detatched/attached MD5 sums, GPG signatures or the like could be pretty easily added in.
You're right, it is needed.
Learning HOW to think is more important than learning WHAT to think.
Okay, how about:
.aa-.aj.
split -b 65m filename.iso filename.iso.
breaking the 650+ Mb iso in about ten 65 Mb chunks with the suffixes
Share them on Gnutella, KaZaA and any other P2P services.
Once downloaded, cat all the files together into one and check the MD5 sum (also downloaded, or embedded like RedHat 7.3 does).
Learning HOW to think is more important than learning WHAT to think.
Read the line above. Now, somebody be ambitious and make a package for everything freenet needs in one RPM / deb package and put up a system to make it known. Now we play...
SIG: HUP
There are pleny of other open p2p products.
Freenet scaleable, not vaporware, very much beta.
Alpine.
based on trust
Gnunet. Sounds very open. based on electonic money. also seach for gnet.
chord Very efficient to find files.
distrinet At this stage: vaporware.(there is code....) But if you look at the description it beats any p2p software!
But in the end the network with the most data (gnutella/kazaa) will be used. Note that users will switch networks very quickly. Look what happened to napster.
this is what we need to make the open music movment happen.....people will make music, license it as being free to trade, and then folkes will do more and more of it.....who knows, mabye this can become the "good example" needed to show the courts that P2P file sharing can be done with out infringing the rights of others, and even lead to some mainstream artist releasing some music on the system to advertise.
I am the Alpha and the Omega-3
Using P2P networks for this kind of caching is something that is long overdue and if these guys can pull it off in a major way then I'm all for it.
I'm just not sure that I buy the description of the "Open Content Network":
"the OCN will allow users to download open source and public domain content from multiple peers and mirrors in parallel."
I presume that it could just as easily be used for copyrighted material and is in no sense different from Napster etc. in its restrictions and potential (read: probable) use.
Sounds a bit like a PR thing: our network is for Open Source material, if people use it for other things - well that's none of our business.
Personally, I agree that they should have the right to focus and brand themselves however they want. I also agree that they shouldn't be held liable for the type of files users actually submit (unless they're either actively screening them or branding themselves as the "Illegal Warez Network" or something). I'm just not sure that this approach will help to limit their liability (although I sure hope it does). Or did I miss something and they are proposing some method of ensuring the content meets some guidelines, thus avoiding any of the Napsteresque controversy?
My next sig will be ready soon, but friends can beat the rush!
At least there being honest about there evilness
thank God the internet isn't a human right.
I'd like to draw your attention to the Globe Distribution Network (GDN), like OCN, a content distribution network for freely redistributable software. Its design specifically addresses the problem of deviants abusing the network to distribute other people's copyrighted works and illicit content. In particular, it requires all content published to be digitally traceable to the publisher. If, after publication, someone finds that this content is not free software the content will be removed and its publisher blocked from the network.
The GDN furthermore offers a scalable solution to the problem of finding the nearest replica (i.e., a scalable URI resolver service in OCN terms), and facilities for dynamically replicating content in areas with many downloaders.
Publications on the GDN, the underlying Globe middleware, and its initial implementation (BSD license) can be found on http://www.cs.vu.nl/globe. The best description of the anti-abuse measures of GDN are found in the paper titled ``A Law-Abiding Peer-to-Peer Network for Free-Software Distribution'' published at the IEEE NCA'01 Conference.
I was thinking about this only 3 or 4 days ago.....
hehe. Ah well, I'm glad somebody else is doing it really, I have more than enough on my plate right now. Perhaps they should check out the Creative Commons?
This is similar to an idea I have had for debian, point to point apt. Clients only need to downoad the packages files from the server with md5sums then whenever i apt-get a package its in my local cache :) :)) just by running apt-get and having a net connection
machines neer me can get these files faster
A local debian mirror except its done by apt and i still get my packages list from the debian servers so i know they have the correct md5sums and stuff
however i suspect somone is already doing this
'piracy' is killed off as the only packages that are mirrored ar the ones listed at the debian servers (some on could create a pkg containing the files and host it on there own server but then they are thepoint of access) the servers still hold the originals but it meens that ordinary users can contribute to debian ( a fantastic dist
Swarmcast OCN
Peer to peer downloading of
Open source software
The network operators can kinda identify who they issued the certificate to.
Which means the network operators will have to make deals with notary public offices in every major metropolitan area in all 180-odd independent countries order to be able to certify that people are who they say they are. This can become expensive, and the total cost of maintaining a certificate may rise up to $200 per cert per year, making this situation no better than the SSL cert situation.
Will I retire or break 10K?
read the subject. not much else to say...
This sig has been temporarily disconnected or is no longer in service
Actually the OCN should be safe from attack. The reason is that from the get go is intended to distribute content that is totally legal to distribute. Now certainly some may abuse it, but the problem that Napster ran into was that it so clearly built it's business model on make a profit from contributing to piracy.
The courts are unlikely to shut down a network like this that makes a good faith effort to be legitimate. Most other P2P services establish themselves as trading points for all manner of illegal content. They try to cover this up to look good to the courts but there's no doubt that Kazaa, etc, wouldn't be this popular were it not for piracy.
This sig has been temporarily disconnected or is no longer in service
There was an application called mojonation, which became mnet that does something along these lines I think?
When you "publish" something to the mnet it splits the file in X parts and puts those parts on Y servers. Your download is swarmed from these servers. The file stays on the net as long as there are atleast 1 server per block. Those servers also check what blocks are more popular and "purchase" those blocks from other servers to make the file more easily accessable.
Or so I'm told anyway.
I think the idea is quite nice.
You can read more about it here.
wbr
.haeger
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
I read some comments and I realized that what you need is eDonkey file sharing (here).
...), so it is ideal for large linux distros.
Compare downloading movie from kazaa or from edonkey (speed 1 to 50)
Files are represented as checksums md5 (no filename confusion). It is free, fast, realiable, secure. Files can be uploaded while being downloaded. This insures that a rare file that is wanted by many people will be distributed as quickly as possible. Support multiple server. This file sharing network is primary used for sharing movies, cd images(appz, games,
Check out feature list: here
Check out my paper (to appear tomorrow at http://arxiv.org/list/cs/new - cs.NI/0205058). From the abstract:
"We propose centralized algorithm of dat distribution in the unicast p2p network. Good example of such networks are meshes of WWW and FTP mirrors. Simulation of data propogation for different network topologies is performed and it is shown that proposed method performs up to 200% better then common apporaches".
It's not that P2P is a bad technology, it's just that the 'P' usually stands for 'People'.
For a network to be stable, you need devoted individuals and groups. The Internet is built upon such groups, because it takes a couple of bucks and some configuration to set up a web site. This weeds out 95% of the users who want to set up domains. The 5% remain those devoted to the cause. And those who really want to, are those who are more likely to build a good site. A stable service.
Now, if the bar is lowered so that every yahoo with an internet connection can download a program that sets them up as part of a network, it will be like letting people print their own driving certificates.
Of course, a site costs lots of money, and very few people actually contribute financially (there's that 95% weedout again), so P2P might be the answer. But don't expect stability.
And please don't get me started on the traffic overhead and exploitability.
If you look you will see that many of the people involved here are names known to the Gnutella developer list. These are people who have tried to talk the Gnutella crowd into growing towards the legit market.
Since the Gnutella crowd wants to stay in the land of free movies, porn and music, these guys have gone off and created their *OWN* network with a central certificate authority that will tell you what content is nice and legal and what is suspect. This is the way "good" P2P should be done.
Stik the cert on a floppy and post it to them (charge a nominal amount for the P&P).
At least you can say in your defence, they were at this address, then you find them yourself.
thank God the internet isn't a human right.
We've had several large deployments of files which are a couple hundred megabytes and up, getting sustained downloads of a couple hundred downloaders at once, serving off a dsl line, and it's worked well.
By the way, BitTorrent, Swarmcast, and OCN all check secure hashes under the hood, so data integrity isn't an issue.
On the other hand, 2 CD sales at MP3.com probably makes more money for a band than 4 sales at a record store.
This is a step further for easier Linux distribution. Don't know about you, but I depend a lot on the internet for upgrades to my Linux system. N.B. this is not like downloading a 600MB ISO. I install from CD and then do bite-sized upgrades to individual packages. I use a 64KBps connection. I figure 56KBps wouldn't be that much worse.
Distribution is one of our principal weapons agaist monopolies. Some people don't know Linux, but some do know and can't distribute, for fear of retaliation.
What if you download a game demo with a simplified Linux-on-Windows (something like what was done to run the Doom on DOS)?
I'll probably get modded down for this again, but why not just use Usenet?
Set up an alt.binaries.geektoys and post all the Videogame Demos, Distros, Open Source Software, Movie Trailers and the like that we're all interested in. You can use RARs, PARs, SFVs, etc to make sure the file is downloaded properly. Then the only issue is making sure the checksum matches up with what you got off the original web site.
ISPs already carry Usenet, so the infrastructure is set up, and this is definitely a useful, non-infringing use of Usenet.
"What was I downloading? Why, the latest version of Mandrake!" Sounds good to me...
"Sometimes a woman is a kind of religion, she can save your soul & set you free from all your sins" - Bad Examples
I've been hoping someone would do this for quite a long time now. No more playing with slow mirror ftp sites when I want to get my Linux upgrades.