Project JXTA: Setting the P2P Tone

by Chris Genly June 15, 2001

JXTA is a language and platform independent extensible peer to peer protocol set. The core JXTA protocols are asynchronous and unreliable. For those of you familiar with TCP and client server applications you may find this strange. But the shift from client server to P2P puts different demands on a protocol. Here’s an example peer to peer application that will set the tone for this protocol bias.

Imagine a peer to peer search. Such as the one implemented by the file sharing P2P application, gnutella. The user of a gnutella peer (also called a servant) starts a search for a particular file name. This peer is connected to a number of neighbors. It will broadcast its search to its neighbors. These neighbors will search their file set for the requested file. If they have the file, they will send a search result back to the peer that made the original query. The reply will indicate the address of the peer that has the file, but the search doesn’t stop there. These neighbors will in turn rebroadcast the search to their neighbors. Of course they will not send the search to the peer where they got the search from. The search is rebroadcast in a nuclear chain reaction. It won't take long before a huge number of peers has searched for the file. To keep network traffic down, a search reply is sent only if the file is found. So if the file does not exist, no replies will arrive. If the file exists on one peer, one reply will be returned to the originator. If a lot of peers have the file, a lot of replies will be sent.

From this example we can see a lot of features unique to P2P. A query is sent. The replies are asynchronous. There is no guaranteed timing for replies. Replies may come quickly, some may straggle in very late. The originating peer must be prepared to deal with asynchronous nature of the P2P network.

If a large number of replies come back to the originating peer, the network could get awfully congested in the neighborhood of that peer. Each P2P network is free to drop messages to protect its bandwidth and limit its latency of performance. Each peer added to the network offers the P2P net a set of resources. This makes P2P scalable. But with each new peer comes new resource demands. The demand can scale along with the resources offered. In fact, given the chain reaction which P2P encourages, the demand can actually rise much faster than the resources added. A typical P2P strategy to limit the network from being consumed with requests is to give messages a time to live (TTL). The originator of a message sets the TTL. Maybe it’s five. Each time a message is rebroadcast, the TTL is decremented. When the TTL reaches zero, the message is no longer rebroadcast. This limits the radius in which a P2P message can travel, and defines a peer’s P2P horizon.

The P2P search network example is made up of a large set of peers. Peers may come in to existence and wink out of existence at any time. A search peer must be very agile and tenacious about staying connected to the P2P search network. As it loses neighbors, it must be prepared to find new neighbors. In general, how agile and tenacious a peer has to be depends on what kind of P2P application it is running.

Gnutella supports one large super group. That is, every gnutella peer is part of the gnutella network and participates in search and file sharing. You can imagine that a good gnutella peer might make use of some sophisticated traffic limiting strategies. JXTA introduces the concept of a P2P group. A group is a set of peers which cooperate and communicate with each other. A peer may participate in more than one group. Groups are natural way to divide up a network. A music file sharing group might be huge. But a group may also be small. For example, a group of people wanting to text chat with each other is a natural way to define the group of peers. A small group, like the chat group presents less technical challenges than a huge group. If a chat group gets very large, there will be pressure among users to split the chat in to several groups. Each one handling a different topic. This will keep the traffic down in each group. Thus small groups will not require sophisticated methods to manage traffic.

After reading the search example you may object saying that not all P2P applications can use unreliable messaging. Some P2P applications will demand reliability. You may also object that some applications require a good idea of who is in the group. In a chat application, you want to know who you are talking to, and who drops out of the conversation. You are right to object. JXTA does not prohibit reliable transmission and reliable group information.

So how does JXTA handle its charge of supporting a wide variety of P2P applications. The answer is it provides a set of core protocols which are asynchronous and unreliable to accomplish the most common P2P tasks, in addition it allows services to be added to a peer, and thus add new protocols.

JXTA also introduces the concept of an application. An application is a user of JXTA services. JXTA services are protocols that can be shared among various applications. As an example, a gnutella like application could be written using JXTA. The application would provide a user interface, a way to define a set of files to share, a way to initiate a search, and a way to display the results, and a way to initiate a file transfer. This application would make use of a set of services, a reliable point to point file transfer service, a distributed search service, a discovery service to locate other peers, and so on.

JXTA does not require a specific transport protocol. JXTA messages can be transmitted from one peer to another using a number of protocols. TCP, HTTP, Bluetooth and many other protocols can be used. The JXTA reference implementation allows protocols to be plugged in. Other implementations, in a cell phone for instance, my have one wired-in protocol.

So when you are told a peer is a JXTA peer, you won’t quite know what it is. This is in contrast to Gnutella. When you are told a peer is a gnutella peer, you know exactly what it is, because you know exactly what protocol it implements. A JXTA peer is not a complete definition of a peer. To complete the definition of a JXTA peer, you need to know what transport protocols it uses, what services it provides, and what application is running on that peer.

The JXTA community will provide the core JXTA protocols to build upon. The community will write many kinds of services to be employed by application writers, and it will provide many interesting applications. The JXTA community will provide the core, the services and the apps implemented in any number of languages on any number of platforms. The hallmark of these various implementations is that they will interoperate. A JXTA 3D rendering compute farm application running on a Linux system will interoperate with those running on windows, Mac, BeOS and Java.