John Robb at Userland has defined a set of constraints for what he considers to be next generation of P2P. I appreciate that he’s put Userland architecture interests online — it generates conversation. However, I am concerned about the interpretation of “P2P”, for what is, essentially a lightweight server system.
Requirement one: The ability for individual users to create subnets where authorization is required before use is enabled.
It’s interesing that people talk about sub-nets and authorization. For true P2P security, the same rules of trust and security must be established with all peers, sub-net participants or not. Rather than create new authentication and security for each individual sub-net, the same security mechanisms and trust definitions must apply to all P2P nodes. Otherwise, any one P2P node that’s on a wire that has physical access to the secure sub-net is a point of vulnerability. And I guarantee that there will be one node that’s connected to the Internet, making all nodes insecure.
However, applying security measures across all possible P2P nodes is going to be a burden on a system — security takes bandwidth. And that’s not the biggest issue — security within P2P nodes implies control. Most forms of authentication and authorization are based on these functions being provided by a central server.
As we’ve seen recently with Morpheus, central points of entry make a P2P system vulnerable.
If this issue is straight user signon and authorization to access of services, then you’re not talking about P2P — you’re talking about a more traditional server/client application. A true P2P system must have a way for each peer to establish a secure connection and determine identity and accessibility without reliance on any specific server.
Yeah. “Gack” is right.
Requirement two: The ability to publish structured content such as a complete web site or web app to a multi-million person network without flooding the publisher’s PC.
I know where this one is going, and I’m sorry, but this is based on a flawed vision: pushing content out to an individual client rather than having the client connect to a centralized source. In addition, this isn’t really a requirement for P2P, but a specific application’s functional need. It’s important to keep the two separate as we discuss the requirement in more detail.
At it’s simplest, published content is nothing more than files, and any P2P file system will work, including Freenet and Gnutella. But in reality, with published content we’re talking about structure as well as files. In addition, the published content also implies an ability to access and re-access the same publication source again and again in order to get fresh content.
Traditional P2P file transfer systems are based on the concept that you’re after a specific resource, a single item — you don’t care where you get it. For published content, the source is a key factor in the peer connection.
As for the issues of scalability, again, traditional P2P networks don’t have an answer that will work in for this requirement because of that single port of content. This would be equivalent to a Gnutella network and only one node on that network has Michael Jackson’s Thriller. As relieved as we are about this, this does put some serious limitations on a P2P-based resource system.
However, once we get beyond the stretch to the P2P paradigm this requirement necessitates, the same concepts of store and forward of Freenet could work for this requirement, except that you’re not talking about intermediate nodes storing an MP3 file — you’re talking about the possibility of massive amounts of information being dumped on each individual intermediate node.
The only way for this to work would be to stripe the material and distribute the content on several nodes, basically creating a multi-dimensional store and forward. Ugh. Now, what was the problem with the web?
Requirement three: The ability to connect subscribed users in a given subnet to each other via Web Services in order to enable a new class of applications that share information (but don’t utilize centralized resources).
The whole principle behind P2P is connecting peers to each other. However, maintaining a true connection in order to successfully conduct a transaction, that’s the key. I once wrote the following functionality for a P2P transaction:
Transaction reliability — the old two-phase commit of database technology appears again, but this time in a more challenging guise.
Transaction auditing — a variation of the two-phase commit, except that auditing is, in some ways, more fo the business aspect of the technology.
Transaction security — we need to ensure that no one can snoop at the transaction contents, or otherwise violate the transaction playing field.
Transaction trust — not the same thing as security. Transaction trust means that we have to ensure that the P2P service we’re accessing is the correct one, the valid one, and that the service met some business trust criteria (outside of the technology realm with the latter).
Service or Peer discovery — still probably one of the more complicated issues about P2P. How do we find services? How do we find P2P circles? How do market our services?
Peer rediscovery — this is where the iron hits the cloud in all P2P applications I know of. You start a communication with another peer, but that peer goes offline. How do you take up the conversation again without the use of some centralized resource? Same could also be applied to services.
Bi-directional communication — This is a reference to HTTP’s asymmetric nature. Peers share communication; otherwise you’re only talking about the traditional web services model.
Interesting challenge. As far as I know, at no one has met it yet…at least nothing that can handle complex data with a single point of origin.
Outside of the listed requirements, John discusses that the next generation P2P systems needs some form of development environment. He states, “Notice, that in this system, the P2P transport is important but generic — it is just a pipe.” He also says “… this system it doesn’t have to be completely decentralized to avoid legal action.”
Last time I looked, decentralization was the basis of P2P. And can we all forget the damn copyright issues for once and focus on what P2P was meant to be: total enablement of each node within the Internet?
John, you have specified requirements of which some, but not all, can be met by P2P-based functionality. Let me emphasize that “some but not all” response again.
You’re really not packaging requirements for the next generation of P2P systems; what you’re packaging is the requirements for “Next Generation Radio”. It’s important not to confuse this with what’s necessary for P2P systems.
I am Superwoman. What makes me Superwoman? Because I meet all the requirements for being Superwoman. And what are the requirements for being Superwoman?
Being me.
It just doesn’t work that way.
