The Jxta solution to P2P

Sun's new network computing platform establishes a base infrastructure for peer-to-peer application development

1 2 3 Page 2
Page 2 of 3
Peer Discovery Protocol (PDP)
Peers use this protocol to discover all published Jxta resources. Since advertisements represent published resources, PDP essentially helps a peer discover an advertisement on other peers. As the lowest-level discovery protocol, PDP provides a basic mechanism for discovery. Applications might choose to use higher-level discovery mechanisms. PDP serves as a low-level protocol over which higher-level discovery mechanisms can be built.
Peer Resolver Protocol (PRP)
Often in the network, peers send queries to other peers to locate some service or content. The Peer Resolver Protocol intends to standardize these queries' formats. With this protocol, peers can send generic queries and receive responses.
Peer Information Protocol (PIP)
PIP can be used to ping a peer in the Jxta environment. A peer receiving a ping message has several options: It can give a simple acknowledgment, consisting only of its uptime. It can send a full response, which includes its advertisement. Or it can ignore the ping. Thus, there can be peers capable of receiving messages but not sending responses.
Peer Membership Protocol (PMP)

Peers use the Peer Membership Protocol for joining and leaving peer groups. This protocol recognizes four discrete steps used by peers and thus defines Jxta messages for each of these actions:

  • Apply: A peer interested in entering a group can apply for a membership to the group membership authenticator. The authenticator responds by sending back an acknowledge message to the peer.
  • Join: After an apply, the peer can choose to join the peer group.
  • Renew: To update their membership information in the group, peers use the renew message.
  • Cancel: Peers can choose to cancel their peer group memberships.
Pipe Binding Protocol (PBP)
In the Jxta environment, peers use pipes to access services. A peer can bind to a pipe's end at runtime and access services. The peer can create a new pipe, bind to an existing pipe, and unbind from a pipe. For those cases, the peer uses the Pipe Binding Protocol.
Endpoint Routing Protocol (ERP)
This protocol helps a peer route messages to a destination. The ERP helps peer routers query other peer routers about available routes for sending messages.

Jxta defines a core set of peer group services, a basic set of services required to create a fully functional Jxta network. Each core service implements one of the Jxta protocols for simplicity's sake. For example, the core Discovery Service is implemented over the Peer Discovery Protocol. The other core services are Membership Service, Access Service, Pipe Service, Resolver Service, and Monitoring Service.

The Jxta Java Binding

The best way to see the above protocols in action is to explore the Jxta Java Binding, the Jxta reference implementation in Java. Developers can build on the existing implementation or choose to implement their own version of the protocols in the languages and platforms of their choice. Though the reference uses the HTTP and TCP/IP transports because of their simplicity and popularity, you can implement the Jxta protocols on any transport protocol, depending on the network topology.

Let's quickly look into the Jxta Java Binding as it stands today.

The class organization

The Jxta Java Binding consists of two main class hierarchies:

  • The net.jxta.* classes
  • The net.jxta.impl.* classes

The first package contains all the Jxta interfaces, which are the Java interfaces for the Jxta protocols and core building blocks. The second package contains these interfaces' implementations. The interfaces and their implementations must be clearly separated. Let's dive into these packages.

Where is my peer?

A peer is an independent, asynchronous entity in the network associated with a peer ID. You might consider an instance of running code as a peer. Currently, a boot class (net.jxta.impl.peergroup.Boot), which provides a main() method, starts a peer.

A peer's capabilities depend on the groups to which it belongs. But, by virtue of just being a peer, every peer exhibits some minimum capability -- having an ID, for instance. That means that there must exist at least one peer group that every peer must be a member of: the world peer group. Also called the platform peer group, the world peer group is represented by the class net.jxta.impl.peergroup.Platform, an implementation of the PeerGroup class (net.jxta.peergroup.PeerGroup).

Peer group nesting

Consider peer P1, a member of peer group PG1, a group that offers a basic discovery and search service. Consider another peer group in the network, PG2, which offers a more advanced search service. P1 must join PG2 to utilize the advanced search service while simultaneously using the discovery service provided by PG1. To achieve that functionality, we can use peer group nesting. With peer group nesting, services available from one peer group overload one or more of another peer group's services. That provides an inheritance relationship: The first peer group, in this case PG1, acts as a parent, and the second, PG2, as the child. In this case, the child's search service overloads the parent's. Thus, once P1 joins PG2, you can expect the peer groups to nest as WorldPeerGroup/PG1/PG2. Note that the world peer group is always at the top of the hierarchy, as all peers are implicitly a default part of that group.

Peer groups as applications

An important abstraction in binding, an application (net.jxta.platform.Application) is anything that a peer group can initialize, start, and stop. It is interesting to note that one peer group (net.jxta.peergroup.PeerGroup) usually starts another peer group (refer to the discussion on peer group nesting) and is hence an application. An exception is the platform (or world) peer group. It is not started by any other peer group and forms the base of the peer group hierarchy. An application defines three methods: init(), startApp(), and stopApp().

The methods in the Application class are as follows:

public void init(PeerGroup group, Advertisement adv);
public int startApp(String[] args);
public void stopApp();

Pipes and endpoints

As mentioned earlier, pipes are virtual communication channels used for messaging in the Jxta environment. Pipes are represented by the Pipe interface (net.jxta.pipe.Pipe), which is considered a service and is thus inherited from the Service interface (net.jxta.service.Service). Pipes are further classified as either input pipes (net.jxta.pipe.InputPipe) or output pipes (net.jxta.pipe.OutputPipe). The PipeService class (net.jxta.impl.pipe.PipeService) contains the pipe implementation used in binding.

Pipes are implemented over endpoints. The Endpoint class, net.jxta.impl.endpoint.Endpoint, is a collection of transport endpoints. Endpoints can either broadcast messages using the propagate() method or send messages to a specific endpoint using an endpoint messenger implementation (net.jxta.impl.endpoint.EndpointMessenger). An endpoint messenger implementation depends on the transport protocol for which it is implemented. For example, the class net.jxta.impl.endpoint.http.HttpNonBlockingMessenger is an endpoint messenger implementation for the HTTP protocol.


All advertisements in the binding extend from the abstract superclass Advertisement (net.jxta.document.Advertisement). Depending on the type of resource that advertisements represent, they can be further classified as peer group advertisements (net.jxta.protocol.PeerGroupAdvertisement), pipe advertisements (net.jxta.protocol.PipeAdvertisement), and so on. An AdvertisementFactory class (net.jxta.document.AdvertisementFactory) creates advertisements. The factory helps to hide the advertisements' actual implementations.


All services implement the Service interface (net.jxta.service.Service). A Service is an application and thus extends the Application interface. Because Service objects cannot be manipulated directly, a Service interface usually accesses a Service object. For example, the Discovery interface (net.jxta.discovery.Discovery) represents the Discovery Service. The DiscoveryService class (net.jxta.impl.discovery.DiscoveryService) represents the Discovery Service's implementation. The DiscoveryService class is not accessed directly, but rather through a DiscoveryInterface interface (net.jxta.impl.discovery.DiscoveryInterface).

Jxta community projects

As mentioned earlier, project Jxta is an open community effort with participation from open source developers, technology enthusiasts, and academics alike. Anyone can join to contribute towards the technology's growth. features many interesting projects. Let's look at a few of them.

The Jxta shell

The Jxta shell is a sample application built on top of the Jxta Java Binding. It provides interactive access to the Jxta environment through a command-line interpreter. It resembles a Unix shell and provides similar commands to access the Jxta primitives. You can download the Jxta shell from the shell homepage, and easily install and configure it. Jxta shell commands deliberately resemble Unix commands. The Jxta shell also supports the pipe operator (|).

The Jxta shell is designed such that most of its commands are separate from the shell framework and dynamically loaded when invoked. That allows developers to easily add their own commands to the shell. A few built-in shell commands are:

The man command is a manual system for the Jxta shell. This command gives a list of all available commands in the Jxta shell. Obtain information about each command by using the man <command name> option.
The clear command clears the shell's screen.

The env command displays the values of all the shell session's environment variables. Seven environment variables are defined by default:

  1. consin: Default console input pipe
  2. consout: Default console output pipe
  3. stdin: Default input pipe
  4. stdout: Default output pipe
  5. stdgroup: Default peer group
  6. rootgroup: Default net peer group
  7. shell: Root shell
Sets a shell environment variable.
The cat command prints a Jxta object's contents.
Displays the information about a peer or a peer group. With no options, it displays information about the local peer.
Displays information about all the rendezvous peers to which the peer is currently connected. It also shows whether the peer is itself a rendezvous peer.
Use the peers command to discover other peers in the same peer group. Running the command with no option lists the peers already known by the current peer. You can do that because advertisements of peers once discovered by the shell are cached. Running the command with the -r option sends a discovery request to find remote peers. You can use the peers -f command to flush the cached peer advertisements.
The groups command resembles the peers command; it discovers peer groups.
Imports an external file into a shell environment variable.
Exports a shell environment variable's contents into an external file.
The mkadv command makes an advertisement from a shell environment variable. The advertisement can be a peer group advertisement or a pipe advertisement.
The mkpgrp command creates a new peer group using a peer advertisement. If no advertisement is specified, the shell creates a clone of the net peer group.
The join command allows a peer to join a peer group.
The leave command allows a peer to leave a peer group previously joined with the join command.
The mkpipe command creates an input or output pipe. Pipes are created from an input pipe advertisement document.
The talk command can be used for simple, minimal instant messaging between two remote peers. It consists of three steps. First, the user registers, which essentially entails the creation of a new talk advertisement for that user -- a one-time process. The user registers via the talk -register <nick> command. Second, once the registration is complete, the user must log in before he can chat. He logs in via the talk -login <nick> command. The user can then search for other users using the talk -search command. Third, once he locates another user, he can send messages with talk -u <nick> <destinationUserName>.
Use the exit command to exit the shell.

The Jxta Content Manager Service

The Jxta Content Manager Service, popularly referred to as CMS, allows sharing and retrieving of content -- represented by a unique content ID -- within a peer group. The CMS also features a content advertisement that provides metadata about the content. In addition, the service allows content management on the local peer. And it lets a peer browse and download content from remote peers.


InstantP2P is a peer-to-peer instant messenger implemented on Jxta. It contains functionality for one-to-one instant messaging, group chat, file sharing, and so on. It is available for the Linux, Solaris, and Win32 platforms. Devices running Personal Java 3.1 can also support InstantP2P.

InstantP2P can serve as a good example from which to learn Jxta. Users can log in to the application using a nickname of their choice. They can then search all Jxta groups available in the network and join groups of their liking. Users can also view all peers who are group members. The chat option can be used for a one-to-one chat, and a group chat allows users to chat with a group. The share option allows users to share content with other group members. Users can also search content shared in the group. InstantP2P internally uses the Content Manager Service to allow file sharing.

The Jxta promise

In this article, I have introduced you to peer-to-peer networking. You have discovered what Jxta provides to the P2P world. I have also shed light on certain important terminologies and concepts used by programmers creating P2P applications with Jxta.

Jxta holds promise as a low-level platform for P2P application development. While the technology is in its early stages today, it is expected to mature over time to provide a robust, reliable framework for P2P computing. Because Java is the preferred language for applications designed for heterogeneous environments, it is the natural choice for P2P applications. I hope this article has sparked enough interest in you to start exploring the world of P2P and Jxta.

Navaneeth Krishnan is senior product engineer at Aztec Software and Technology Solutions, where he has designed and developed several e-commerce solutions and frameworks for clients. He is an active P2P enthusiast and currently deeply involved with Jxta. He owns iPeers, a Jxta community project that deals with the integration of artificial intelligence in P2P networks.
1 2 3 Page 2
Page 2 of 3