Tag: P2P

Categories
Technology

P2P and relying on HTTP

The Don Box discussion about HTTP was a good read with valid points.

From a P2P, not a web services perspective, we need to guarantee certain capabilities in P2P services that we take for granted in more traditional client/server environments. This includes the following:

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 Don’s reference to HTTP’s asymmetric nature. Peers share communication; otherwise, you’re only talking about the traditional web services model.

The file transfer nature of Napster or Freenet, and the IM nature of Jabber don’t necessarily consume all of these aspects of P2P applications, so haven’t necessarily pushed the P2P bubble to the max. However, when we start talking about P2P services — a variation of web services one could say — then we know we’re going to be stretching both our technology capabilities and our trust of the same.

Fun!

Categories
Technology

Radio and P2P – not

Recovered from the Wayback Machine.

Okay, I’ll be the first to admit I’m a mood today, but there’s few things that tick me off more than this application of “P2P” to any old technology that comes along. And then this proud standing back as if all is explained.

Give me a break.

John throws this simple little sentence out as if the word comes from on high:

What’s the killer app for a desktop content management system?  P2P + Web Services + desktop CMS (Radio).  Killer combo.

I posted a comment to the note asking where the P2P was in this equation. I am not expecting a response.

There is no P2P with Radio. Period. Please don’t tell me “full peers” or any bullshit like that. If there is an assumption of a hard coded IP that is online 7×24 then that is a server. I don’t care what you call it.

Web services. Yes. Desktop content management. Yes. But Radio has no P2P element.

It is a good product and I enjoy using it, and I think it’s interesting that Userland has been able to get all these people to do all this work for no pay via the new publishing paradigm but there is no P2P element in Radio!!

Categories
Technology

Radio and P2P

Recovered from the Wayback Machine.

John did respond, in his comments, to my query ,in his comments, about Radio and P2P:

I need a real P2P system to pull this off. Something that can go through firewalls and NATs. Unfortunately, most P2P systems are run by people that are only interested in Napster-style file transfer (essentially a file pile). There is more to this: apps and Web Services.

Appreciation for answering, but one request: don’t go there — don’t go with the limitations of P2P as an answer to the question of P2P expectations in Radio. I can point out more than one application that uses P2P based technologies and whose focus is not based on file manipulation, starting with a mainstream app John probably knows — Groove.

What does Userland want from P2P? Web services imply a server, which implies a traditional approach to serving application needs. Been there. Done that. Next page, please.

If you’re talking publish and subscribe, now we know we’ve been there and done that. Can anyone say “channels”? The technology is neat and seems to be coming into its own — again — but how P2P is this? Isn’t this dependent on a Radio cloud handling the intermittant connectivities of the individual Radio installations? Just as Groove does within its cloud?

Really, with clouds like these, I’ll never have iron-poor blood, will I?

The technology is neat and important and a real step in the right direction, but I don’t think this is what John was talking about. Or is it?

What do you need from a real P2P System, John? If you articulate this, you might find there are people out there with an answer. But we can’t take a shot if you don’t ask the question. Given the right information, we’d enjoy the opportunity, you’d enjoy the opportunity, we’d all learn from the experience, and we’d all have fun.

And we might even come up with some interesting ideas in the process.

Categories
Technology

De-centralization

Recovered from the Wayback Machine.

Julian talks about a rant at the de-centralization mailing list at Yahoo. What he says is right on — specifically:

There’s another couple of truisms here that “standards are useless without implementations” and so “There are only de-facto standards”. Everything else is just academic (mutual) mind games.

If a standard isn’t implemented in the real world, it’s nothing more than a theoretical wanna be wrapped up in pretty white paper, tied with a standards group approval bow.

BTW, I used to go out to the de-centralization group and read the postings regularly, until I found one day that the whole exercise irritated me…badly. As much as I admire some people in the P2P community, there is no one in the field who is either God or the Ultimate Answer Person.

I took a look at the group after Julian’s posting. You know what? I found myself getting irritated all over again. And discouraged.

Categories
Technology

P2P Networks

Recovered from the Wayback Machine.

I checked out Circle as well as Chord as P2P networks. These are excellent efforts and should be note to anyone who is interested in P2P systems. As with KaZaA, much of the P2P cloud is transient and located on the peers themselves. The folks at Userland should look at how this can be done with Radio 8.0 if they want a true, distributed backend to the product.

I have a feeling the cloud part isn’t the issue — it will be the Radio backend and this assumption of one controlling application per weblog. At least, that’s what I found when I started peeking around a bit. Perhaps folks more knowledgeable about Radio will have a better idea.

Back to the P2P systems: aside from a key entry point (and all of these systems need this and there’s a reason why) the P2P clouds are without iron. Aside from the key entry point.

Why is the entry point needed? Because each P2P circle is too small (yes it is) to make it efficient to send a bot out into the open Internet, knocking at IPs looking for a specific node of any one of these systems. All P2P systems are too small for this to be effective, Napster, Gnutella, and so on. Think about it — how many nodes are online now in the Internet? I wouldn’t even try and guess the number but I imagine millions and millions. Now you have a P2P network with about 200,000 nodes. Needle in haystack. Right?

Well, not necessarily. Depending upon the dispersion level of the nodes of the P2P network, it might not be that difficult to find an entry node into the network. So with a bot and a handshake protocol implemented at each node you could have a golden gateway — an entry point totally without iron.

However, the problem with this approach is you then have to have a bot for every system you want to join: Groove, Gnutella, Circle, and so on. What a pain.

Wouldn’t it be better to have all these systems provide a common form of identification as well as a common handshake and direction protocol and then have one type of bot that’s smart enough to tap on the door of the nearest P2P system and say “I’m looking for so and so”? And wouldn’t it be better to have each system learn about the others when contacted, such as when a bot returns to a node with a connection into Circle, it also happens to have information about the nearest golden gateway node to Gnutella?   And would it be such a resource burden to have the node check every once in a while to make sure it’s neighboring nodes are still online? So that when our bot of discovery comes calling, it’s given up to date information?

What’s the cost of a ping?

You know, I have so many bots crawling my servers that I’m amazed it’s still standing at times. But none of them work together. If they did, and if they were smarter, and if our sites had something a bit smarter than just open ports, firewalls, or web servers — then maybe we could do without DNS and centralized repositories of information such as UDDI.

Just some more grand ideas to throw out and see if people think I’m full of little green beans again.