Interoperable P2P: Jxta

Troy writes: "This article went up today (on developerWorks) about the Open Source project called Jxta, which is a community-run attempt to build a utility application substrate for peer-to-peer applications. Anything with an electronic heartbeat can become a Jxta peer." A nice high-level overview of how Jxta is supposed to work.

Comments

Jxta vs. Freenet

[Guppy06]

Well?

Jxta seems to be a bit better at being a true P2P network without having to know the address of a node before-hand, but Freenet seems to handle bandwidth better by distributing popular files across multiple nodes as needed.

Sun is apparently trying to keep a "hands-off" posture with IP security on Jxta, while Freenet carries it one step further by making it difficult to find who posted or holds "bad" information at any given time.

So... which will ultimately be the better/prefered choice of users?

Re:Jxta vs. Freenet

[Hobbex]

They are not comparable. With Freenet, we are trying to achieve a very specific task - publishing data and making it available in a manner that disassociates with any physical location. The Freenet protocol works for this task, and this task only - it would not be possible to implement anything like jxta over Freenet, and nor would it be (regardless of what people who do not understand the technology may say) possible to implement Freenet, or anything like it, within jxta.
From what I understand, and while I'll disclaim that I could be wrong I did read through the specifications, jxta is basically a generalized Gnutella. To begin with, the idea seems nice enough: Why is Gnutella limited to searching for string matches, wouldn't it be nicer if messages could carry arbitrary queries so that one could use the same network to ask for "Porn jpgs matching \BIG BOOBIES\" and "2 billion computer cycles to render BIG_BOOBIES.3ds"?

Yes, it would be nicer, but then, the limitation of searches is not really Gnutella biggest problem , is it? Gnutella's biggest problem is scalability and performance, and - this is what people don't seem to want to hear - by generalizing the queries completely, you have closed the door on trying to make this any better (for searching to work without broadcast you need either sorting or (centralized) indexing - arbitrary queries are neither sortable nor indexable). And for that reason you cannot implement and network like Freenet, or Oceanstore, or Chord, or anything that even attempts to optimize routing beyond the everybody-screams-at-the-top-of-their-voice approach, on top of Jxta.

The interoperability bug that has caught certain people in regards to the group of programs called "P2" is misguided. It is like "standards" and "interoperability" has become such a holy cow in many circles that people will simply not hear the physical arguments for why interoperable fire and water simply isn't a very good idea for either.Not that it really matters - all the people I have met who are actually doing anything worthwhile in this are seem to understand this very well.

Re:Jxta vs. Freenet

[trix_e]

Freenet seems to be *much* more about anonymous and safe dissemination of information without the fear of censorship or forgery. While it *can* be used as a general P2P service layer, it's not exactly designed to be the pipes under any old P2P app.

Jxta, on the other hand is shooting to be just that, a general services layer.

Big difference. Both may flourish but for different reasons. (IMHO Freenet is a very specific demonstration of a concept, but won't take off as anything much more than that...)

Java, JINI, JXTA...

[MosesJones]

Sun are a strange bunch, a company where the vi v emacs wars can really kick off as two of the developers are there (Gosling for emacs, Joy for vi). JXTA is another of Bill Joy's babies, its meant to be a language/protocol independent offering for peer to peer solutions, which was originially what http://www.jini.org said they would do (Jim Waldo).

JXTA is a nice idea, and there are some good papers from JavaOne on the subject. But given that Sun's marketing might is behind J2EE will JXTA really be given a chance ?

IMO the answer is probably yes, JXTA and Java are part of a two pronged attack at next generation devices, this isn't really PC to PC type applications but device to device, most of the next generation mobiles will be running Java, some will not and most service provider cells will not, JXTA enables the bridge between the Java world of the device and the big bad world of networking to interact.

Strange how the best ideas come without marketing strategies. Java was an inhouse project which aimed for 10,000 downloads. Will the same explosion happen with JXTA in a wireless world ?

PCs suck, time to distribute.

Re:Java, JINI, JXTA...

[jeffy124]

I beg to differ on some of your comments. Jini is a means of building ad-hoc networks for devices and services, while Jxta could be built on top of Jini to build a quick network of shared resources. Jini originally started out as a wireless or other device thing, but has found uses in software. J2EE is not really related to Jini/Jxta, but it can build itself off of the services they provide. J2EE is intended for large-scale enterprise applications like databases, and it's possible to do that using traditional methods or utilizing ideas offered by Jxta and/or Jini.

However, I do agree with that this is a way of attacking and going after the wireless market. Sun needs a marketing dept like that of MS, one that is aggressive and sees oppurtunity in tying things together. Let's just hope that un doesn't go too far with that ; )

Making the same mistakes all over again

[Carnage4Life]

The problem I have with distributed computing technologies from Sun and the other Unix companies is that they are typically never fully standardized by vendors. CORBA suffered from the fact that the spec was too generic and yet to complex and thus didn't enforce that ORBs should provide enough default services which lead to all sorts of interesting vendor lock in as its almost impossible to find two ORBs that implement the same exact set of services.

Although J2EE decided to go a different route by specifying a comprehensive list of minimum requirements it is sizable enough that no two vendors currently completely implement all of the same functionality (or at least not the last time I checked).

Jxta seems to be taking the generic-ness route which from experience leads to incompatible implementations and vendor lock-in. Particularly telling where the following excerpts from the article

In other words, a Jxta application that meets the minimum specified interoperable requirements superficially and does not interoperate in any meaningful way with others can still be in accord with the Jxta specification. However, it is anticipated that the viral growth of P2P applications and services will force vendors to embrace interoperability as a key product feature. The consequences of this design decision are left to be tested by the trials and tribulations of open market forces.

Sounds like a journey that is starting with the wrong step to me.

Oh, the Possibilities

[Vilk]

Imagine, pirating music from the comfort of your couch. Can a toaster play MP3s yet? I bet they'll be able to soon.

Intelligently routing generalised queries

[Sanity]

Agreed, agreed, agreed. One minor quibble though:

for searching to work without broadcast you need either sorting or (centralized) indexing - arbitrary queries are neither sortable nor indexable

I don't think this is nescessarily true. The minimum requirement for being about to do a Freenet-style best-first search for something is that you can define an equality operator, and a closeness operator (ie. "A is closer to B than C is").

The closeness operator sounds a bit like sorting, and anything that can be sorted can also have a closeness operator, however not everything that can have a closeness operator can be sorted. There is no reason why a more general query couldn't conform to these requirements. Generally speaking it would probably require some form of "fuzzy matching" of metadata to an SQL-style query. Of course this would require some constraints on the nature of the query, but it could still be much more flexible than Freenet's current lexographic search.

Re:Jxta is not all that

[hardburn]

My point is that Jxta is making development decisions that are best left up to implementers. For instance, the Freenet developers are never going to allow broadcast anything, but if Freenet were made within the Jxta framework, they would have to live with broadcast node announcement (despite the fact that the experimental 0.4 Freenet is getting support for a uber-efficent node announcement that scales linearly).

I have figured it out...

[Hobbex]

For those who don't get what Jxta is good for, don't worry, it took me a while too, but I think I have it.

Jxta is an attempt to combine XML, Java, and Gnutella. Obviously, this unholy hybrid can have only one purpose - to make a computer program so slow time runs backwards!

Jxta is not all that

[hardburn]

Jxta was created by Sun to be a "framework" for P2P networks. What exactly that means is rather vague. It appears to make basic development decisions that are better left up to indiviual projects (such as broadcast seaches). TCP/IP is really the only thing most P2P networks have in common, and even that could often be easily replaced with a diffrent underlieing protocol if it was necessary.

There are several other assumptions that Jxta makes that it shouldn't. See this article for more information.