The Jxta solution to P2P

Today’s Internet is witnessing a revolution. A revolution that strives to change one of its basic features. A revolution where network endpoints — or clients, such as desktop PCs, mobile phones, PDAs, and the like — are demanding better network status. A revolution fueled by applications like Napster and Gnutella, applications that bring an end to a server-dominated Internet. A revolution hailed as P2P.

P2P (or peer-to-peer) networking is a network model where, depending on an operation’s context, any node can operate as either a server or a client. P2P provides certain interesting capabilities not possible in traditional client/server networks, which have predefined client or server roles for their nodes.

In this article, I introduce you to P2P networking and compare it with client/server networking. I also introduce you to Jxta (pronounced jux-ta), a P2P computing platform pioneered by Bill Joy, Sun Microsystems’ chief scientist and corporate executive officer; currently, Jxta is being molded by hundreds of open source developers. Jxta holds tremendous promise for the P2P world. It defines a set of protocols that developers can use to build almost any P2P application. At the same time, these protocols are flexible enough to be easily adapted to application-specific requirements. While Jxta does not dictate any particular programming language or environment, Java could potentially become the language of choice for P2P application development for obvious reasons: portability, ease of development, and a rich set of class libraries.

P2P: An overview

Today, the most common distributed computing model is the client/server model. Figure 1 depicts the typical client/server architecture.

In the client/server architecture, clients request services and servers provide those services. A variety of servers exist in today’s Internet — Web servers, mail servers, FTP servers, and so on. The client/server architecture is an example of a centralized architecture, where the whole network depends on central points, namely servers, to provide services. With no servers, the network would make no sense; without them, how would Web browsers work? Regardless of the number of browsers or clients, the network can exist only if a server exists.

Like the client/server architecture, P2P is also a distributed computing model, but there is an important difference. The P2P architecture is a decentralized architecture (see Figure 2), where neither client nor server status exists in a network. Every entity in the network, referred to as a peer, has equal status, meaning that an entity can either request a service (a client trait) or provide a service (a server trait). Figure 2 illustrates a P2P network.

Though peers all have equal status in the network, they don’t all necessarily have equal physical capabilities. A P2P network might consist of peers with varying capabilities, from mobile devices to mainframes. A mobile peer might not be able to act as a server due to its intrinsic limitations, even though the network does not restrict it in any way.

Both networking models feature advantages and disadvantages. You can visualize from Figure 1 that as a client/server network grows (that is, as more and more clients are added), the pressure on the central point, the server, increases. As each client is added, the central point weakens; its failure can destroy the whole network.

A P2P network delivers a quite different scenario. Since every entity (or peer) in the network is an active participant, each peer contributes certain resources to the network, such as storage space and CPU cycles. As more and more peers join the network, the network’s capability increases. Hence, as the network grows, it strengthens. You won’t find that kind of scalability in client/server architectures.

A P2P network also differs from the client/server model in that the P2P network can be considered alive even if only one peer is active. The P2P network is unavailable only when no peers are active.

You pay the price for the advantages a P2P network offers, however. First, managing such a network can be a nightmare compared to managing a client/server network, where administration is only needed at the central points. Therefore, the enforcement of security policies, backup policies, and so on proves complicated in a P2P network. Second, P2P protocols are much more “talkative” — as peers join and exit the network at will — than typical client/server protocols. This transient nature can trigger performance concerns. (See “Bandwidth Barriers to Gnutella Network Scalability” for more information.)

The Jxta solution

Different protocols, different architectures, different implementations. That accurately describes current P2P solutions. Currently, developers use diverse methodologies and approaches to create P2P applications. Standards, abundant in the client/server world, are noticeably absent in the P2P world. To tackle this deficit, Sun developed Jxta.

From the Jxta vision statement:

Project Jxta is building core network computing technology to provide a set of simple, small, and flexible mechanisms that can support P2P computing on any platform, anywhere, and at any time. The project is first generalizing P2P functionality and then building core technology that addresses today’s limitations on P2P computing. The focus is on creating basic mechanisms and leaving policy choices to application developers.

Jxta strives to provide a base P2P infrastructure over which other P2P applications can be built. This base consists of a set of protocols that are language independent, platform independent, and network agnostic (that is, they do not assume anything about the underlying network). These protocols address the bare necessities for building generic P2P applications. Designed to be simple with low overhead, the protocols target, to quote the Jxta vision statement, “every device with a digital heartbeat.”

Jxta currently defines six protocols, but not all Jxta peers are required to implement all six of them. The number of protocols that a peer implements depends on that peer’s capabilities; conceivably, a peer could use just one protocol. Peers can also extend or replace any protocol, depending on its particular requirements.

It is important to note that Jxta protocols by themselves do not promise interoperability. Here, you can draw parallels between Jxta and TCP/IP. Though both FTP and HTTP are built over TCP/IP, you cannot use an FTP client to access Webpages. The same is the case with Jxta. Just because two applications are built on top of Jxta doesn’t mean that they can magically interoperate. Developers must design applications to be interoperable. However, developers can use Jxta, which provides an interoperable base layer, to further reduce interoperability concerns.

XML in Jxta

Undoubtedly, the first step towards providing a universal base protocol layer is to adopt a suitable representation that a majority of the platforms currently available can understand. XML is the ideal candidate for such a representation. The Jxta developers recognize that XML is fast becoming the default standard for data exchange. XML provides a universal, language-independent, and platform-independent form of data representation. XML can also be easily transformed into other encoding. Hence, the XML format defines all Jxta protocols.

Although Jxta messages are defined in XML, Jxta does not depend on XML encoding. In fact, a Jxta entity does not require an XML parser; it’s an optional component. Just think of XML as a convenient form of data representation used by Jxta. Smaller entities like a mobile phone might use precompiled XML messages.

Understand the Jxta jargon

Before proceeding any further, let’s quickly look at the various concepts in Jxta.

Peers

Any entity on the network implementing one or more Jxta protocols. A peer could be anything from a mainframe to a mobile phone or even just a motion sensor. A peer exists independently and communicates with other peers asynchronously.

Peer groups

Peers with common interests can aggregate and form peer groups. Peer groups can span multiple physical network domains.

Messages

All communication in the Jxta network is achieved by sending and receiving messages. These messages, called Jxta messages, adhere to a standard format, which is key to interoperability.

Pipes

Pipes establish virtual communication channels in the Jxta environment. Peers use them for sending and receiving Jxta messages. Pipes are deemed virtual because peers don’t need to know their actual network addresses to use them. That is an important abstraction.

Services

Both peers and peer groups can offer services. A service offered by a peer individually, at a personal level, is called a peer service, a concept equivalent to centralization. No other peer needs to offer that service; if the peer is not active, the service might become unavailable.

Peer groups offer services called peer group services. Unlike peer services, these services are not specific to a single peer but available from multiple peers in the group. Peer group services are more readily available, because even if one peer is unavailable, other peers offer the same services.

Codats

Codat (Code/Data), in Jxta, means content that could be either code or data. Codats can be published, discovered, and replicated if necessary.

Advertisements

An advertisement publishes and discovers any Jxta resource such as a peer, a peer group, a pipe, or a codat. Advertisements are represented as XML documents.

Identifiers

Identifiers play a key role in the Jxta environment. Identifiers specify resources, not physical network addresses. The Jxta identifier is defined as a URN (Uniform Resource Name). A URN is nothing but a URI (Uniform Resource Identifier) that has to remain globally unique and persistent even when the resource ceases to exist (see Resources for more information on URNs and URIs).

World peer group

Every Jxta peer is, by default, a member of the world peer group. Each Jxta peer intrinsically knows the world peer group and can join this peer group, even if it can’t find any other peers on the network. Even disconnected peers are members.

Net peer group

On a local network, the network administrators can usually configure a peer group that every peer on the network can join: the net peer group. This group resembles a DHCP (dynamic host configuration protocol) service. The net peer group provides peers with a global connectivity according to restrictions imposed by the administrators.

Rendezvous peers

A rendezvous peer is a special peer that stores information about other peers it knows about by caching these known peers’ advertisements. Thus, a rendezvous peer can help peers discover other peers in the network. Rendezvous peers can also forward discovery requests to other rendezvous peers.

Endpoints

Endpoints are destinations on the network and can be represented by a network address. Peers don’t generally use endpoints directly; they use them indirectly through pipes, which are built on top of endpoints.

Routers

Anything that moves packets around the Jxta network is called a Jxta router. Not all peers need to be routers. Peers that are not routers must find a router to route their messages.

The Jxta protocols

The key to Jxta lies in a set of common protocols defined by the Jxta community. These protocols can be used as a foundation to build applications. Designed with a low overhead, the protocols assume nothing about the underlying network topology over which an application that uses them is built.

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.

Advertisements

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.

Services

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. Jxta.org 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:

man

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.

clear

The clear command clears the shell’s screen.

env

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

setenv

Sets a shell environment variable.

cat

The cat command prints a Jxta object’s contents.

whoami

Displays the information about a peer or a peer group. With no options, it displays information about the local peer.

rdvstatus

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.

peers

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.

groups

The groups command resembles the peers command; it discovers peer groups.

importfile

Imports an external file into a shell environment variable.

exportfile

Exports a shell environment variable’s contents into an external file.

mkadv

The mkadv command makes an advertisement from a shell environment variable. The advertisement can be a peer group advertisement or a pipe advertisement.

mkpgrp

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.

join

The join command allows a peer to join a peer group.

leave

The leave command allows a peer to leave a peer group previously joined with the join command.

mkpipe

The mkpipe command creates an input or output pipe. Pipes are created from an input pipe advertisement document.

talk

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>.

exit

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

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.

Source: www.infoworld.com