I think you are definitely onto something here. (Of course, I am biased since for the past year we've been working on a system that does exactly that.) Check out http://www.peermetrics.com or send me an email for more discussion about this (if interested.) Of course, email would be easier, but look at the project info at peermetrics; it might give you some ideas...
Peter
This is cool. I find the concept of "generic" (not just web) services even more intriguing. What if anyone could publish electronic services?
Think about it--a published Napster server and Napster client, for example. Anyone can get the services and become either the client or the server. All you need is some powerful search capabilities.
The question remains: what is Amazon.com without the website? Just a software "service" running on somebody's machine? I wonder if in the future every business will be nothing but a piece of software (and a marketing team for the brand name, of course)...
Bertelsmann AG settled with Napster by creating an alliance. However, 'Four other recording companies aside from Bertelsmann AG are still plaintiffs in the suit. --ZDNet News.' Unless those other guys settle, Napster is still being sued. What surprises me is this: 'Bertelsmann AG's e-commerce group BeCG will loan Napster cash to create a "membership-based service" and in exchange buy a piece of the company.'
Wait a minute! They are going INVEST in a company that has FOUR other pending lawsuits?! The only explanation I see is that Bertelsmann already has an informal agreement with the other recording companies. Of course, they will join the "alliance"--it will give them control over the company that might take them out of business.
Let's call the search / catalog / resource discovery transfers that happen in a p2p world "query transfers". What I am talking about are the transfers that happen after you hit the search button with the name of your favorite mp3 in the search box. The goal is to get a list of peers that have that mp3, given n total (or just "relevant") peers on the network.
So, how many transfers does it take? The naive answer is that in the *worst case* you get O(n*n) query transfers: every peer has to query all of its neighbors and in turn every neighbor has to query its neighbors, etc. If everyone is connected to everyone else, you need n*n transfers, right?
Only if you are using Gnutella after Napster gets shut down 'cause if you have a complete list of the peers on a network you can just search all of them directly for your mp3, resulting in O(n) transfers. The problem is, you would need to maintain a gigantic database with at least an IP for every peer on the network. Bummer.
Of course, instead of keeping the entire database you could keep some of it and then spread the rest over the other peers. This is an old hat for the distributed caching folks. In the p2p world, Freenet is doing something like this, but for a different reason...
Ok, once you distribute the database, you need some way to order (or cluster) the peers to minimize the number of transfers required to find the right chunk of the database. Instead of the boring space-time tradeoff, you get a more uncommon space&time-bandwidth tradeoff.
In conclusion, with some clever clustering you can get O(n*log(n)) transfers. The guys I work with agree. The key here is the base of that log. I think it can be pretty large (again with some clever clustering) making it an "almost" O(n) search.
Some food for thought--what if you "bundle" some of the search requests so that the same search requests (or at least similar ones) go through several "common" search points. Then, what if these points can determine what peers or groups of peers DO NOT have the right information without even searching them? Hmm... a sub-linear search? How "sub-linear"? Is that even possible?
Maybe the latest p2p apps will not help Napster, but at least the excitement they create will help the people formerly known as Napster employees.:)
On a somewhat related topic, I think that a successful p2p model would be able to support topologies ranging from purely clientclient all the way to clientserver. Some problems are just better suited for a clientserver approach whereas others are more clientclient (sorry, peerpeer.)
I haven't seen many people talk about this... but how will the latest p2p software integrate with what's out there already? I just don't see the browser and the web being replaced by the Groove client. In which case, Groove has to somehow integrate with the web. How?
In addition, I thought Groove had to eventually replicate with a "replicating server" or whatever it is called making it not a pure p2p app. As far as I know, there is NOT a single working (or even semi-working) p2p app out there 'cause namespace management & resolution, search, and security get ya.
I agree. I think that the business potential of p2p is the "one-click install" and simplified administration of the software on a network. If you don't have centralized servers, there is no need to pay for their maintenance.
It is questionable if an open source app will ever come out. Right now what all the p2p people are trying to figure out is a way to make money. Their only value is in the code they possess and if they make it open source will they ever see the green?
Sharing executable code is something that will need to happen for the p2p paradigm to succeed. Remember, in a true p2p world you are literally running executable code on other people's machines. For now that's not a big problem because there are only a few well-known p2p applications (Napster, Gnutella, etc.)
What about the future when there are hundreds? What is lacking is an operating system for managing p2p executable code. Desktop OSes are no good because they assume that you trust your local applications.
A p2p OS would need a way to control the security and system resources for each application because 1) part of the app is on someone else's machine, 2) you don't want the p2p app saturating your network or formatting your hard drive.
Slashdot Mirror
I think you are definitely onto something here. (Of course, I am biased since for the past year we've been working on a system that does exactly that.) Check out http://www.peermetrics.com or send me an email for more discussion about this (if interested.) Of course, email would be easier, but look at the project info at peermetrics; it might give you some ideas... Peter
Think about it--a published Napster server and Napster client, for example. Anyone can get the services and become either the client or the server. All you need is some powerful search capabilities.
The question remains: what is Amazon.com without the website? Just a software "service" running on somebody's machine? I wonder if in the future every business will be nothing but a piece of software (and a marketing team for the brand name, of course)...
Wait a minute! They are going INVEST in a company that has FOUR other pending lawsuits?! The only explanation I see is that Bertelsmann already has an informal agreement with the other recording companies. Of course, they will join the "alliance"--it will give them control over the company that might take them out of business.
So, how many transfers does it take? The naive answer is that in the *worst case* you get O(n*n) query transfers: every peer has to query all of its neighbors and in turn every neighbor has to query its neighbors, etc. If everyone is connected to everyone else, you need n*n transfers, right?
Only if you are using Gnutella after Napster gets shut down 'cause if you have a complete list of the peers on a network you can just search all of them directly for your mp3, resulting in O(n) transfers. The problem is, you would need to maintain a gigantic database with at least an IP for every peer on the network. Bummer.
Of course, instead of keeping the entire database you could keep some of it and then spread the rest over the other peers. This is an old hat for the distributed caching folks. In the p2p world, Freenet is doing something like this, but for a different reason...
Ok, once you distribute the database, you need some way to order (or cluster) the peers to minimize the number of transfers required to find the right chunk of the database. Instead of the boring space-time tradeoff, you get a more uncommon space&time-bandwidth tradeoff.
In conclusion, with some clever clustering you can get O(n*log(n)) transfers. The guys I work with agree. The key here is the base of that log. I think it can be pretty large (again with some clever clustering) making it an "almost" O(n) search.
Some food for thought--what if you "bundle" some of the search requests so that the same search requests (or at least similar ones) go through several "common" search points. Then, what if these points can determine what peers or groups of peers DO NOT have the right information without even searching them? Hmm... a sub-linear search? How "sub-linear"? Is that even possible?
Maybe the latest p2p apps will not help Napster, but at least the excitement they create will help the people formerly known as Napster employees. :)
On a somewhat related topic, I think that a successful p2p model would be able to support topologies ranging from purely clientclient all the way to clientserver. Some problems are just better suited for a clientserver approach whereas others are more clientclient (sorry, peerpeer.)
I haven't seen many people talk about this... but how will the latest p2p software integrate with what's out there already? I just don't see the browser and the web being replaced by the Groove client. In which case, Groove has to somehow integrate with the web. How?
In addition, I thought Groove had to eventually replicate with a "replicating server" or whatever it is called making it not a pure p2p app. As far as I know, there is NOT a single working (or even semi-working) p2p app out there 'cause namespace management & resolution, search, and security get ya.
It is questionable if an open source app will ever come out. Right now what all the p2p people are trying to figure out is a way to make money. Their only value is in the code they possess and if they make it open source will they ever see the green?
What about the future when there are hundreds? What is lacking is an operating system for managing p2p executable code. Desktop OSes are no good because they assume that you trust your local applications.
A p2p OS would need a way to control the security and system resources for each application because 1) part of the app is on someone else's machine, 2) you don't want the p2p app saturating your network or formatting your hard drive.