The Trouble with JXTAby Adam Langley
Last week, amid much fanfare, Sun released the first JXTA specification. JXTA was announced at the first O'Reilly P2P conference in February 2001 in San Francisco. After the presentation Tim O'Reilly asked Bill Joy, "What actually is it?" because the presentation was so content-free. Well, it's still very vague, but we now have a better idea. In this article I'll explain why P2P projects are going to leave JXTA well enough alone.
The P2P ideas out there at the moment are many and varied -- from the famous but uninspiring design of Napster to the more interesting designs of Free Haven, Freenet, Mojonation, SETI@Home etc. Peer to peer is an active area of research and an example of Darwinian selection of ideas at work.
What does an active research community absolutely not need? Great big Sun stomping in and slamming down standards left, right and center.
The only thing most P2P applications have in common is TCP/IP; everything else depends on the specific P2P application. This is quite natural when everybody is trying out ideas, because few of the P2P applications share much above the presentation layer. Napster uses an unencrypted link to the server and sends requests in its protocol; Freenet uses an encrypted link and sends requests in a different protocol designed to do very different things.
JXTA is a confining protocol designed for a specific type of P2P application. It has already made a number of design decisions.
Take, for example, broadcasting. JXTA broadcasts its discovery messages and broadcasts within its groups. This is a perfectly valid decision to make for a specific application -- but it's not general enough.
JXTA provides protocols for the basic functions -- create groups, find groups, join and leave groups, monitor groups, talk to other groups and peers, share content and services.
-- Raffi Krikorian, "Hello, JXTA!"
These are exactly the kind of assumptions JXTA shouldn't be making. Broadcasting within groups is fine for small-scale systems. It doesn't work when you scale up, as the problems with Gnutella have shown. And when you're broadcasting, a verbose protocol like XML is just what you don't want.
|Is JXTA a big leap forward for P2P developers, or do you agree with Langley?|
|State your position here|
But let's assume you've implemented your wonderful new P2P application on JXTA. Let's say it's an instant messaging client because they seem to be popular at the moment. Well, you can't have all your clients in the world in one group, broadcasting to each other, unless your ambitions stretch to only ever running about 20 clients. So you have to send messages to trusted servers which unicast the message to the right peer.
This isn't in keeping with the JXTA protocol, but I'm sure you can manage it somehow. Now you want to interoperate with another P2P instant messaging application -- since you're both using JXTA that should be easy. But really you've gained nothing but a lot of bloat. You have to handle another protocol with another set of servers. This is no different from the current situation where you're trying to interoperate with another protocol using TCP/IP, except that you should already have the XML parser.
You also haven't gained any time. You might just as well have implemented the application using sockets. It would be much simpler and quicker to do so. I fail to see where JXTA fits in at all. If your design drops into JXTA very nicely, then by all means use it. But the idea that JXTA is defining a common core of P2P protocols is scary because there's so much more, and it's those protocols which are interesting.
JXTA is a solution, desperately looking for a problem.