The Trouble with JXTA
by Adam Langley05/02/2001
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.
|
Related Articles: |
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.
|
| |
| 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.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 18 of 18.
-
Standards, standards, standards
2001-06-11 18:55:18 dalexis [Reply | View]
It's interesting how much of the current P2P "pioneers" are so hostile against the creation of standards. Whether JXTA will become the predominant standard or not is not an issue. And while I agree with the opinion that we'd rather not see giants like Sun dictating standards (especially when they'll try to lock you in to Java), you have to at least give them credit for getting serious with the standards discussion.
Langley and others are starting to sound like Timmy McVeigh with weird fears about the big ol' gov'ment squashing free speech. Please! It's time to realize that standards are necessary. P2P will die if it continues with the anachistic chaos of protocols that currently exist! And YES, "standards" like JXTA have their place because P2P can be used for many more productive scenarios than silly, adolecent attempts to circumvent copyrights and evil "censorship".
Grow up, pack the ego in the closet, and lets get on with some real work.
-
Money vs Opinion
2001-06-04 13:26:47 arakon [Reply | View]
"From: raytaft
[clip]
I am certainly not saying that Sun nailed it, quite the obvious, however this position, this article you wrote, is a counter marketing point and will only confuse those with less than an acute attention for the obvious.
Ray
"
I'm not sure I understand? Just because his company recieves funding for a p2p project means he's automatically disqualified from critising? I can't recall him stating the solution he's working on is better then Sun's (or universally applicable to all P2P problems!). In fact, he's saying that there's too many different framework's and approaches at the moment to have a cure-all solution. Frankly, I don't see how much it will help considering a large portion of P2P problems havn't been solved yet. (can we say SCALING?)
I assume you have other arguments on WHY Sun's approach is a good one, or reason's the the problem's presented are baseless? Or is your only problem political? And if so, Why isn't Sun guilty of over-hyping this, since there interest in this is Purely money? (Look at Jini's licensing! Rediculous. And not turning Java over to be standardized!)
From what I understand of this "technology", it's just another helper library that probably won't get much adaptation, because the problems it solves only make it easier for a small scope of devlopers (and that not by much). Very similar to the way DirectPlay is used for games - developers use some features, but "roll there own" for the critical stuff. I find this especially true when thinking of SOAP, XML-RPC, etc.
- Arakon
-
Sun Bashing
2001-06-01 23:44:18 raytaft [Reply | View]
Hi Folks - Long time listener, first time caller.
Adam, this timing of this article seems remarkably ironic seeing you took $4M smakaroos from Intel to deliver something conceptually identical. Do the words “Politically tone deaf” mean anything?
Driving the P2P community away from a technology because you are frightened about it, (or the long arm of Intel), really makes your position look weak to those who are keeping open minds about where we need to go to monetize P2P.
I am certainly not saying that Sun nailed it, quite the obvious, however this position, this article you wrote, is a counter marketing point and will only confuse those with less than an acute attention for the obvious.
Ray
-
Sun Bashing
2001-06-22 12:11:48 agl [Reply | View]
Quote:
Adam, this timing of this article seems > remarkably ironic seeing you took $4M smakaroos from Intel to deliver something conceptually identical. Do the words “Politically tone deaf” mean anything?
I did? I'd like to see it please and I think Intel would be interrested too. Which Adam do you think I am - cos I'm not that rich.
-
JXTA is a giant step forward for P2P developers
2001-05-29 05:40:38 mrubioc [Reply | View]
Standards is the only way to achieve that
all people can use technologies.
May be Adam Langley forgot TCP/IP origins or the
way to make Java accesible to any developer trought
Java Community Process.
Sun's JXTA project is a great job, but this is only
true if all companies contribuites to success.
Thanks.
-
Re: alternates to heavy XML-based protocol approaches / reality check
2001-05-09 09:29:40 juantay [Reply | View]
"again, xml is not a standard, nor a protocol. it is merely a standard way of specifying standards. since apps built on top of jxta will not have to deal with xml directly and will be leveraging the jxta api, the choice of xml is merely convenience for the jxta development team allowing them to take an off the shelf parser and use that to process messages.
sun is wrong. you don't make a protocol succesful by pushing it forward as a protocol. who cares about a protocol? not even the academics, beyond a certain point. what people care about is an application of the protocol (or any core technology for that matter) that can ONLY be accomplished reasonably well with this new protocol. i.e. a killer application. there is no killer app for jxta such that one couldn't do the exact same thing with a home-brew p2p protocol.
let's not fool ourselves. this is no great technological revolution, and it is not even a very interesting evolution. i am not microsoft lover, but the way they are approaching their messaging platform is much more mature. they want it to be adopted first, through massive dissemination of msn messenger and then hailstorm, finally tying all these "killer" apps which are widely adopted with a unified, underlying messaging platform. first come out with a cool application, then talk about the platform. this is not networks 301. this is th real world."
ceterus paribus
I think We're all way off in this including Adam. Rereading I see that JXTA is merely a set of concepts. The implementation is not the same as JXTA.
Concepts:
1) Piping from one peer to another.
2) The Grouping concept. (What the word 'Peer' means!)
3) Monitoring and metering.
4) A security layer.
http://java.sun.com/features/2001/02/peer.html
Other than that:
"The rapidly-growing set of distributed applications and services suggest a model that complements the client-server model while emphasizing direct communication between Internet users, not mainly from users at the Internet’s edge to servers located at its core. Rather than clients and servers having a vertical relationship, both can exist as equal peers on the network — despite different performance characteristics."
- Project JXTA: An Open, Innovative Collaboration
I can't see Not using XML in a world of web services even if I don't completely understand it.
"In theory, JXTA can be independent of any format used to encode advertisement documents and messages. In prac-tice, it uses XML as the encoding format, mainly for its convenience in parsing and for its extensibility."
Project JXTA: A Technology Overview
speed isn't everything.
"JXTA is defined as a set protocols, which use XML-encoded messages. As such, it stays away from APIs and remains independent of programming languages, so that it can be implemented in C/C++, Java, Perl, or other languages. This
means heterogeneous devices with completely different software stacks can interoperate through JXTA protocols."
Project JXTA: A Technology Overview
No api's.
"JXTA technology is designed to be also independent of transport protocols. It can be implemented on top of TCP/IP, HTTP, Bluetooth, HomePNA, and many other protocols. This means that a system built on top of JXTA functions in
the same fashion when the system is expanded to a new networking environment or to a new class of devices, as long as there is a correct transport protocol handler for the new networking protocol."
Project JXTA: A Technology Overview
Totally radical.
"And with small, simple building blocks that are easy to build upon, JXTA technology frees developers from having to invent their own framework — enabling them to focus on building new, innovative, distributed computing applications."
- Project JXTA: An Open, Innovative Collaboration
Just like Java.
--
I also don't think it fair to say that this came from Sun, that Sun is just laying down standards. They are laying down concepts however. This is Bill Joy's child. It came from his mind and who else would know about the coming interoperability with everything else? Concepts that he's been thinking about for years and years and worked on for about a year I think in his Aspen Group. So, he's just basically giving us the concepts and a probable road of standards is pushed to fit in with everything else.
You and Adam are correct. There IS hardly anything to JXTA and that's the great thing about it.
Juan Taylor
-
alternates to heavy XML-based protocol approaches / sun's jxta fantasies
2001-05-08 18:12:23 ceterusparibus [Reply | View]
"XML can be many standards in a way, No?
If there are going to be all these devices then I perceive XML as the only way to go because you can have diversity within the standard of XML. A very Rich protocol indeed! So by the time p2p goes mainstream within gadgets and processing is up to par, jXTA should be there to take control. ;-)"
with all due respect, xml being many standards has nothing to do with anything. xml is like agreeing on an alphabet. you can form diverse (or even nonsense) words from the same alphabet, but that does not guarantee that those who agreed to the alphabet will understand the meanings of the words. understanding the meaning of these words is analagous to, as i said earlier, making protocols actionable.
again, xml is not a standard, nor a protocol. it is merely a standard way of specifying standards. since apps built on top of jxta will not have to deal with xml directly and will be leveraging the jxta api, the choice of xml is merely convenience for the jxta development team allowing them to take an off the shelf parser and use that to process messages.
sun is wrong. you don't make a protocol succesful by pushing it forward as a protocol. who cares about a protocol? not even the academics, beyond a certain point. what people care about is an application of the protocol (or any core technology for that matter) that can ONLY be accomplished reasonably well with this new protocol. i.e. a killer application. there is no killer app for jxta such that one couldn't do the exact same thing with a home-brew p2p protocol.
let's not fool ourselves. this is no great technological revolution, and it is not even a very interesting evolution. i am not microsoft lover, but the way they are approaching their messaging platform is much more mature. they want it to be adopted first, through massive dissemination of msn messenger and then hailstorm, finally tying all these "killer" apps which are widely adopted with a unified, underlying messaging platform. first come out with a cool application, then talk about the platform. this is not networks 301. this is th real world.
-
Re: sun's domination ploy and alternates to heavy XML-based protocol approaches
2001-05-07 15:14:18 juantay [Reply | View]
"..in short, don't worry about data representation and creating a standard way to represent all data (thus incurring ineffeciencies due to the necessary generality of this task), instead focus on providing easy ways for people to make your protocol actionable. that's what really matters. with technologies such as Java Reflections, now this protocol->method/action binding doesn't even have to be compile time, so there really is no argument against such an approach.
ceterus paribus"
XML can be many standards in a way, No?
If there are going to be all these devices then I perceive XML as the only way to go because you can have diversity within the standard of XML. A very Rich protocol indeed! So by the time p2p goes mainstream within gadgets and processing is up to par, jXTA should be there to take control. ;-)
Juan Taylor
-
JXTA a roll of the dice?
2001-05-04 10:19:59 cletefrade [Reply | View]
Because the value of framing the discussion on standards can be worth billions, it would seem to be impossible to ignore the effect of financial/marketing elements of companies on the development of standards. Even if this attempt to "grab the reins" of the P2P phenomena fails in complete control, it could be argued that from a business perspective, there is a sufficient return on investment to try.
JXTA may not be a very good standard at all, but from the perspective of a corporate officer, it is good enough to try. There may not be a way to remove the reward for half-baked specification grabs without destroying the economy. The only recourse for those with intellectual integrity is to check for loaded dice. The limited scalability and minimal definition of the JXTA specification makes me want to look up Sun's sleeves. If they are honest sporting types, they won't mind at all.
Patrick S Lasswell
-
sun's domination ploy and alternates to heavy XML-based protocol approaches
2001-05-04 07:26:14 ceterusparibus [Reply | View]
it was funny watching bill joy speak at the Jxta unveiling. he said something to the effect of, "just like tcp/ip provides the basis for the internet, and http does for the web, we would like to build jxta as the fundamental protocol for p2p systems"... innocent? not.
http and tcp/ip are completely open, not sponsored by corporations and very very simple. most people here would be familiar with http, which, especially in it's earlier versions, was extremely simple to implement and extremely lightweight. that's why these protocols rule the world today.
even today, you can implement a 15 line perl web server script for simple document delivery. you can choose to implement protocol subsets because the notion of a protocol request is not the same as that of a valid "document". using XML for a p2p network binds you to that notion, in addition to imposing overhead, which as an earlier poster said, is not optimal for scalability reasons.
it goes back to the argument, what is xml really good for? it's good for a lot of things, but maybe not as a data format for implementing light weight protocol messages. that's what p2p protocols have to support - their very nature is such that nodes cannot always be assumed to have high bandwidth connections to the internet.
as far as the ease of interoperability is concerned, this is just off the top of my head, but how about this:
instead of using XML and embedding parsers in every p2p client / server, implement a protocol any way you want. even simple, lightweight text messages without the overhead of XML. then, implement a module that binds each protocol primitive to an action - make the action map readable. for instance, in java, create a class that understands your simple protocol, and allows methodnames to be registered for each protocol primitive. you could then use reflections to load the appropriate actions (methods/classes, whatever) based on what message you receive.
for the more oft-used languages, one could even come up with either code templates, or a generation tool for this sort of module. then, i could implement an IM client and if your IM protocol represents messages with MSG <text here>
that's not a problem for me, because I've bound the msg display code in my client to be invoked whenever it receives that message. And, you may even publish your actionMap module for anyone to obtain and embed.
in short, don't worry about data representation and creating a standard way to represent all data (thus incurring ineffeciencies due to the necessary generality of this task), instead focus on providing easy ways for people to make your protocol actionable. that's what really matters. with technologies such as Java Reflections, now this protocol->method/action binding doesn't even have to be compile time, so there really is no argument against such an approach.
ceterus paribus
-
Re: XML and Groups?
2001-05-03 16:16:06 juantay [Reply | View]
"The idea of broadcast groups only works in very small groups. This isn't going to work on any large scale. Like I said, if your application is only small scale and fits with JXTA - that's fine.
But groups are not a central concept in P2P apps by any meaning of the word."
caution: P2P Newbie speaking..
You can't create the new lizards and hominoids without Groupings though. P2P not only pushes toward groupings but it's already about Groupings, Gnutella, Napster, Freenet etc. This is simply what the masses will want because it creates VALUE. The very word "Peer" deals with Groupings!
JXTA is to p2p one could say as the World Wide Web is to the Internet. But what happened to
Gopher? If you want to cater to the masses then you have to go down that route - the route
of Groupings to create a much needed VALUE proposition. (Freenet might be a gopher for a time and then contribute value to the JXTAnet down the road based on what was discovered maybe.)
Groupings are not just about applications themselves but is a general idea that embraces the whole and entire sphere of whatever you do in p2p outside of protocols themselves. From sociological groups to useful groups to technical groupings on the server side. For instance, how would there be any real value to p2p on enterprises without groupings?
And now wide multicasting is not all there is but though one day it will arrive. All it means is to simply move around the spheres of what's possible with p2p today. Which may be alot!! and let's not forget that P2P is a tool and not a religion. It's not in isolation outside of the other webs.
Juan Taylor
-
XML and Groups?
2001-05-03 10:53:31 agl [Reply | View]
""All that being said, in several years when the ideal superspecies of p2p have evolved and taken over the p2p world, my question is: what will have been standardized?"
XML and the concept of GROUPS."
The idea of broadcast groups only works in very small groups. This isn't going to work on any large scale. Like I said, if your application is only small scale and fits with JXTA - that's fine.
But groups are not a central concept in P2P apps by any meaning of the word.
-
standards will arrive- when and what?
2001-05-02 16:51:04 juantay [Reply | View]
"All that being said, in several years when the ideal superspecies of p2p have evolved and taken over the p2p world, my question is: what will have been standardized?"
XML and the concept of GROUPS.
Groups are the heart and soul of P2P. and XML will be Ubiquitous, therefore a necessary infrastructure. Adam Langley should see that JXTA isn't a product that just came out yesterday but it's probably a tad bit more of a long term project than what Bill Joy/Sun wants to reveal. Yet the effects are startling.
Juan Taylor
-
standards will arrive- when and what?
2001-05-02 15:23:44 [Reply | View]
Ok, I've heard that it's too early to standardize, or that we should interoperate not standardize, and I have heard utopian arguments of darwin's origin of species metaphorically describing competition between competing p2p solutions many of whom will die and the rest who will presumably mutate, possibly due to radiation... or bit rot...
All that being said, in several years when the ideal superspecies of p2p have evolved and taken over the p2p world, my question is: what will have been standardized? I don't mean "evil corporation" standards, or "bad, too-early standards" or "inefficient, political standards". I mean GOOD standards, righteous standards, "evolved" standards, even (gasp) "defacto standards" like gnutella or ICQ...
So what will they be?
And, since they WILL exist (even if it takes a while to filter out the bad ideas and distill a utopia of good ideas)...
Wouldn't it be ok for some companies, big and small, to try to imagine what those standards might be?
--
Damien Stolarz
dstolarz@static.com
Chief Technical Officer
Static Online, Inc.
& member of p2p working group,
Technical Architecture Committee
Ask yourself, "What has the p2p working group done for me lately?"
(818) 968-7626 cell
http://www.p2pwg.org
http://www.static.com
-
JXTA Newbie responds
2001-05-02 15:08:41 juantay [Reply | View]
"The P2P ideas out there at the moment are many and varied"
This simply means it's a good time for JXTA doesn't it?
"Peer to peer is an active area of research and an example of Darwinian selection of ideas
at work."
Then let's get together to create intelligent mammal(s) based on open Standards.
"What does an active research community absolutely not need? Great big Sun stomping in and slamming down standards left, right and center."
Hey, this is in the hands of the open-source community to change whatever they want!
"The only thing most P2P applications have in common is TCP/IP; everything else depends
on the specific P2P application."
Not good enough.
"JXTA is a confining protocol designed for a specific type of P2P application. It has
already made a number of design decisions."
Same thing may be said about TCP/IP.
"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."
JXTA is new so the structure of both will simply be changed.
"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."
Standards for a Rich Web vs. All kinds of conflicting Protocols. Take your pick. I'll
hold up TCP/IP.
Look, the key point I'll make is that from what I've heard JXTA is not finished being worked out yet and it should be incredibly obvious P2P has to be based on standards.
-
It's the protocols stupid!
2001-05-02 08:25:39 wkh [Reply | View]
"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."
I have yet to read the JXTA docs so I may be
speaking out of school here but if JXTA is in
fact trying to define the "common core of P2P
protocols" then I whole heartedly agree with
Mr. Langley's admonition to stay well away.
Personally I think a much better approach would
be to leverage the hell out of BEEP. While not a
perfect solution for all P2P issues, e.g., it
doesn't support multicasting, it does provide a
solid, standard foundation for experimenting
with various protocol design options.






The loosers are well established standards, and suns customers. We should focus on teaching people to use available tools, instead of switching tools all the time.
It takes perhaps 5 years to become reasonably good in a language or protocol. At that time people begins to learn something about programming, instead of language trivialities.
Unfortuately a lot of programmers never gets this far, because someone told them to learn a new tool instead of becoming better programmers.
Hopefully people will find out some day ... sigh!