JXTA Thoughts

Ken Taylor January 2003

What Does It Take To Change The World?

Big name i.e. Bill Joy, a substantial company and a large amount of interest e.g 12,000 downloads per week and yet the achievements are modest. There seems to be only a few early stage commercial products that use it. Implication - it is hard to change the world, maybe too hard. It is useful to be part of a larger collaboration rather than too independent.

Jun 1999: Bill Joy’s Mantra “Pervasive, Simple & Secure ”

Jan 2000: First Design (Protocols, XML, Messaging, Space)

Jun 2000: First Demo Prototype (Palm)

Nov 2001: New Design (Protocols, XML, Peers, Pipes, PeerGroups)

Committers (5 Sun)

Apr 2001: J2SE Reference Implementation on

Jun 2001: 50,000 Downloads![1]

Weekly Stats
January 11, 2003
Posts
CVS Commits
Downloads
Total Members / 271
419
14,790
12,280

[2]

Why is it Interesting?

Defines communications protocols rather than an environment as opposed to Jini. A discussion of Jini is at and an opinion piece from Tim O’Reilly discussing Jini vs Jxta is at

JXTA has a clever way of traversing a NAT. The device behind the NAT polls for incoming messages with a HTTP GET request. If there is no messages the connection is held open for the period specified by the client or until a message arrives for delivery. The client then makes another HTTP request, which is effectively a ping in our current model. Message delivery is acknowledged with a HTTP 200 response code. Additionally JXTA already has much of what we are only thinking about, particularly to do with ad hoc networking and interaction between multiple back ends that they call relays, discovering relays etc.

It’s Early Stage

The java reference implementation seems to work well but is a bit clunky. Interesting tutorial at that gets the overall ideas across.

It is ostensibly available in other implementations. The C implementation is not available as a binary. There are two flavours of C one for compiling with GNU and Linux and one for Visual Studio and Windows. See I can’t get the Visual studio version to compile as I can’t find a required library “jxtad.lib”. It should be possible to use this C code for a Call Direct implementation but we only need a subset of it and it’s not easy to follow. I’m wondering how well this version works and if anyone is actually using it? The last message on their news list was January last year where they state the Win32 version works. See .

Protocol

The protocol is described at While the whole thing is quite complex the only parts we need to implement are the HTTP transport, i.e client and not server with the commands “poll” and “send” see and the binary message . To interact with a jxta relay/rendevous we need to send a pipe advertisement also but this is just a message hard coded into the right format.

You can try out the protocols from a telnet session to jxta relays/rendezvous’ at 209.25.154.237:9700 and 63.98.225.218:9700 . There is a good http protocol reference at . Testing reveals the jxta http ping command:

GET / HTTP/1.1

Host:

doesn’t give the response the protocol specifies. This indicates that the java reference implementation does not implement the protocol specification. Using the ethereal packet capturing software we had a look at the conversations between a jxta peer configured to use HTTP rather than TCP/IP and work with a relay/rendezvous but not act as a relay or rendezvous and another configured as a relay and rendezvous. A cursory examination creates the impression that there are other differences from the published protocol as well.

Implementation

As the source is published presumably the jxta relay/rendezvous can be incorporated into our existing java backend to extend its functionality. We can use the reference implementation for development on the Call Direct device.

There is a j2me (i.e. java for mobile devices) implementation described at The ideas are described as:

  1. It is reasonable to assume that J2ME will need to act as a JXTA peer without any XML assistance.
  2. J2ME only has an HTTP client and does not have an HTTP server. This means a J2ME device can only send HTTP requests but cannot open ports to listen for and receive incoming HTTP requests.

And;

To connect J2ME devices to JXTA networks, while living within the constraints mentioned above, JXTA4J2ME project designers decided to take some of the load off a J2ME-based JXTA application. JXTA4J2ME peers are given a reduced functionality as compared to a desktop peer, to match the capabilities of a J2ME device.

A J2ME-based JXTA peer only talks to a JXTA Relay (a message relaying peer), which in turn bears most of the message processing (such as XML authoring for advertisements, sending search messages across the JXTA network, and so forth) and relaying burden. A J2ME-based peer, together with a JXTA relay, is functionally equivalent to a normal JXTA peer. Therefore, a J2ME peer will act as an edge device, setting on the perimeter of a JXTA network.

Notice how close this is to our own description of the backend functionality. There is a similar explanation at

The power and flexibility of JXTA come at a price: complexity. A JXTA peer needs to take care of a lot of tasks and process messages at the XML-over-socket level. Such a peer would be too complex to run on most mobile devices. In addition, neither XML nor raw socket support are part of the standard J2ME/MIDP specification. To make JXTA networks available to mobile P2P users, we need a set of lightweight JXTA APIs for mobile devices. The JXME project aims to provide JXTA APIs for the CLDC and MIDP platforms. It can also be used in higher-end J2ME profiles, such as the Personal Profile.

JXME uses relays to connect lightweight mobile peers to the rest of the JXTA network. The relays themselves are rendezvous JXTA peers that have full capabilities to handle pipes, advertisements, and peer group services. Mobile peers communicate with relays through binary-over-HTTP connections using messages conforming to the JXTA Binary Message format. Relays offer a number of peer services to mobile peers:

  • A relay filters out unnecessary advertisements, and strips down those advertisements that are sent in order to save bandwidth.
  • A relay routes (relays) messages to or from mobile peers.
  • A relay translates the relayed messages from JXTA XML format to JXTA Binary Message format, and vice versa, in order to enable interoperability between mobile peers and ordinary peers.
  • A relay acts as a proxy on behalf of its mobile peers. The relay interacts with other peers and pipes, and uses group services.

There is an implementation of this minimalist version described at which I’ve tried successfully. The interface is a simulated mobile phone. We could capture the packets from this with the ethereal product and reproduce the same stuff from the Call Direct device to produce something that will work with the reference implementation.

Tools

Some JXTA message monitoring tools are available at .

This document is available in word format

[1]

[2]