OpenP2P.com    
 Published on OpenP2P.com (http://www.openp2p.com/)
 See this if you're having trouble printing code examples


JXTA Chat, Sans Server

by Nelson Minar
06/05/2001

Comment on this articleTalk about your own experiments with JXTA here.
Post your comments

Project JXTA is an open source peer-to-peer platform that enables a wide range of applications to take advantage of the power of peer-to-peer computing. In this article Clip2 provides an overview of how JXTA can be used to build a simple peer-to-peer chat system. The twist is that the application is built in three modes: centralized, brokered, and decentralized. The differences in implementation reveal the strengths of the JXTA platform.

The source code for the software in this example is online at Clip2.

Is Peer-to-Peer Always Decentralized?

The most exciting thing about the peer-to-peer phenomenon is that it has finally gotten us out of the Web-based doldrums of the early commercial Internet. Much of the growth of the Internet from 1995-2000 was based on the humble Web server, slavishly serving up pages to Web browsers that were nothing but glorified dumb terminals. But the Internet is so much more than that! Peer-to-peer computing reminded everyone what networks could be, by knitting computers together into complex and powerful systems. SETI@Home turned the Internet into the biggest supercomputer; Napster and Gnutella turned it into a system for the unimpeded exchange of music and other files. There is a lot more to come.

Nelson Minar will speak on centralization and decentralization in P2P at the O'Reilly P2P and Web Services Conference, Sept. 18-21 in Washington, DC.

The ironic thing about the term "peer-to-peer" is that it is often used to discuss systems that are, in fact, not really peer-to-peer. SETI@Home peers never actually talk to each other at all! The application design is fully centralized: every client connects to one single server at Berkeley, which coordinates and manages the network. The Napster network is also not decentralized: it is a brokered peer-to-peer network. The actual file transfer takes place in a peer-to-peer fashion, but the directory service that allows music discovery is fully centralized. Napster stands in contrast to Gnutella, which provides a nearly identical application with a radically different, decentralized architecture that relies completely on peer-to-peer communication.

While these systems differ in how they are put together, they share a common characteristic: the individual participant computers contribute something of value back to the network. With Napster and Gnutella, computers contribute their music collections to the Internet, with SETI@Home spare cycles are shared for a common cause. The details of the network plumbing, whether the system is centralized are not, are largely opaque to users.

Centralization vs. Decentralization

Get cracking on your JXTA code

Announcing the OpenP2P.com Project JXTA Developer Contest. Enter your hot JXTA code and win a pass to the O'Reilly P2P and Web Services Conference in Washington, D.C., this September, and a Yopy PDA. Deadline is July 15.

So what's better -- centralized or decentralized? Of course, the answer depends on the situation. A primary advantage to decentralized systems is scalability. With a fully centralized system, the more users there are, the larger the central server needs to be. A decentralized system holds the hope that as peers join the network they are able to share the load of making the system work. The reality of this can be quite complex, as the struggle to keep the Gnutella network functioning has shown us. In addition, decentralized systems can exist without any particular person or company supporting them. Gnutella would be considerably harder to shut down than Napster. The ability of a decentralized system to live in the network, rather than at a particular spot, is particularly interesting.

Centralization also offers a lot of advantages. The aggregation of information in one place allows for easy searchability. A Napster query is fast and complete: a Gnutella search takes many seconds, and never quite searches the whole network. Centralization also greatly simplifies systems that need control over data updates. SETI@Home carefully tracks what data has been processed and by whom: in a centralized system that's a simple matter of a database transaction. Centralized systems also typically do not have peer discovery problems: either the peer with the resource you need is known to the central server (as with SETI@Home), or else the server explicitly helps you find the peer you need (as with Napster). Finally, peers behind firewalls or NAT routers do not suffer as badly in a centralized system, because generally they connect out to the central server which can then help tunnel through any connection problems.

JXTA to the Rescue

Related Articles:

Learning the JXTA Shell

Hello JXTA!

The JuxtaNet

JXTA Takes Its Position

OpenNap Use Crashes

Gnutella: Alive, Well, and Changing Fast

Gnutella and the Transient Web

JXTA provides technologies to replace two of the advantages of centralized systems -- discovery and firewall/NAT traversal. The details of how JXTA itself does this are beyond the scope of this article. In fact, the current mechanisms are largely centralized. But the promise of JXTA is to abstract these problems away from application designers, allowing them to easily build decentralized applications.

JXTA provides discovery capabilities. When a peer joins a JXTA group, it can query that group for anything it may want: a service, a file, a peer with a particular name. The application does not need to worry about the details of how this query operates, because the JXTA platform handles it. It may query a central server (like Napster), or it may query the group in a decentralized fashion (like Gnutella). Either way, the application author gets discovery for free from JXTA.

JXTA also provides firewall routing capabilities. When a JXTA peer joins the network from behind a firewall or a NAT router, it can find another peer on the network who will perform a routing service for it to bypass the firewall. Applications do not need to be aware that this firewall traversal is happening, they simply connect to the peer directly and the JXTA platform takes care of it. A system designer can build a peer-to-peer system in the way they want, without having to rely on a centralized architecture to handle discovery or firewalls.

Chat System Tutorial: Three Cases

To illustrate the advantages JXTA offers, this article presents a single peer-to-peer application written in three styles: centralized, brokered, and decentralized. The application is a basic chat program: users join the network and can send and receive instant messages to each other. The centralized and brokered applications rely on a server to help chat peers find each other, operating much like systems like AOL Instant Messenger, MSN Messenger, or ICQ. However, JXTA makes it easy to build a third, unusual kind of chat application: a fully decentralized one with no server. There are no large-scale precedents for this kind of system.

Lightning JXTA Overview

Before explaining the chat design in detail, it is useful to introduce definitions for the major JXTA concepts:

Peer
A peer is a single participant in the JXTA network, e.g., your computer.
Chat tutorial: Every user is a peer. One peer acts as server (except in the decentralized case).
Group
A group is a collection of peers. A peer joins a group to participate in a particular application.
Chat tutorial: Everyone joins one group.
Service
A service is a capability running inside a peer group. The service may be running on all peers, or just a few within the group.
Chat tutorial: Every peer runs a chat client service. In addition, one peer runs a chat server service (except in the decentralized case).
Pipe
Pipes are the JXTA abstraction of network connections. Pipes have names and exist independently in the peer group.
Chat tutorial: Every service has a pipe.
Advertisement
An advertisement is a description of a particular pipe or service.
Chat tutorial: The pipe for every service is advertised. Clients advertise a pipe for chat messages, servers advertise a pipe for server messages.
Rendezvous Peer
A rendezvous peer is a special peer in the peer group: it caches advertisements and provides them to other peers to enable discovery of services and pipes.
Chat tutorial: In the brokered and centralized cases, the server peer is the rendezvous. In the decentralized case, many clients should act as rendezvous.

Centralized Case

In the fully centralized chat system, there is one single JXTA peer who operates as the chat server. All clients talk directly through that server. At startup, clients register their nickname with the server. When a user wants to send a message to someone, the client sends the message to the server, who then forwards the message on to the other client. The server provides both the discovery and message delivery services.

The JXTA implementation of the centralized chat system contains two services: a server and a client. The server creates a pipe, advertises it to the group, and listens to it. The server peer also operates as a rendezvous: when clients join the peer group, they will connect to the rendezvous service for discovery. The server understands two kinds of messages: registration and chat messages. The registration message contains the nickname of the registering client as well as the advertisement for the pipe the client is listening to. When the server receives a registration message it stores the information away. When it receives a chat message, it looks in its storage, finds the pipe for the recipient, and forwards it along.

The client's job is almost as complex as the server's. When the client starts, it uses the JXTA discovery service to find the pipe advertisement for the server. Behind the scenes, JXTA contacts the rendezvous peer for the group (in this case, the server), and finds the appropriate advertisement. The client then creates a pipe of its own to listen on and forwards the advertisement for this pipe to the server via a registration message. Chat messages are sent to the server for delivery. Independently, the client also listens on its own pipe for incoming chat messages, which it then displays.

The centralized chat application works exactly like a conventional client/server system, only implemented in JXTA. The only advantage JXTA provides in this kind of design is the ability for new clients to find the server when they start up. But because there is only one single server with fixed address this discovery service is not even that useful. It is certainly possible to build centralized applications with JXTA, but not particularly advantageous.

Brokered Case

The brokered case of the chat tutorial works quite similarly to the centralized case. Clients still register themselves with the centralized server. The difference lies in how messages are sent. Rather than route all messages through the server, the clients send messages directly to each other. The server's role is now to help clients find each other.

In detail, the major change is that clients no longer send chat messages to the server: instead, they send them directly to each other. In order to find the client pipe to send a chat message to, the chat client sends a new kind of message, a "client discovery message," to the server. The server responds with the pipe advertisement for the other client node. With that information, the two clients can talk directly to each other.

This design is much like other brokered systems (such as Napster), where the server introduces the two peers to each other and gets out of the way. Implementing this in JXTA is a fair amount of work, particularly because the current system does not directly support query/response types of communication. As with the centralized system, the brokered chat implementation still relies on JXTA discovery to find the server.

The real advantage of JXTA in this kind of brokered system is the firewall traversal capabilities. If both peers are behind firewalls, then in a typical peer-to-peer system they are not able to open a connection to each other. We see this pattern in instant messaging systems like ICQ: they try to do a brokered chat, where clients talk directly to each other, but fall back to a server routed scheme if firewalls or NATs get in the way. JXTA makes this firewall negotiation happen automatically, allowing system designers to write applications as if two peers are talking directly to each other even if they are behind firewalls.

Decentralized Case

Finally, in the decentralized implementation, JXTA shows its full value. In this case the chat system behaves quite differently. There is no chat server service at all, no central peer. All clients just run independently, listening for chat messages and sending them to each other. JXTA discovery provides the capability that makes it possible.

When a client starts up it creates a pipe for itself as in the other two systems. However, instead of using JXTA discovery to find a server and send the pipe advertisement to it, the client just publishes the advertisement itself, to the peer group. When clients want to find each other they no longer need to ask a server, instead they simply use JXTA discovery to find the client directly. Everything becomes much simpler and the code becomes a lot smaller.

The one crucial thing from JXTA that make the system work is the rendezvous peers and the role they play in discovery. In the centralized and brokered scenarios, JXTA discovery was only used to find the original server: discovering other clients was implemented in the chat server application itself. In essence, the server was duplicating the function of JXTA rendezvous, tracking the advertisements of the client pipes. For the decentralized implementation, the client peers in the group are themselves rendezvous peers. JXTA then takes care of making sure that when a client advertises itself, that information is cached on every client node, so that when a client looks for someone else they can quickly find it in the group. This strategy is not without risk: if there are not enough rendezvous or if the synchronization algorithms do not work, then the discovery may not work. However, it is the responsibility of the JXTA platform to maintain and synchronize these rendezvous caches. The application programmer is freed from this burden.

Conclusions

Related Articles:

Learning the JXTA Shell

Hello JXTA!

The JuxtaNet

JXTA Takes Its Position

OpenNap Use Crashes

Gnutella: Alive, Well, and Changing Fast

Gnutella and the Transient Web

JXTA provides two key technologies that aid application authors who are writing peer-to-peer systems. JXTA discovery makes it easy for peers to create services and pipes and publish them in the network: the JXTA platform then takes care of the messy details of making this work. And the JXTA messaging architecture allows peers behind firewalls to receive JXTA messages, without the application authors having to worry about creating their own firewall traversal systems.

However, JXTA is not magic -- the platform itself has to provide technology to produce these capabilities. And this is the point at which it is still too early to evaluate the technology. The current discovery and messaging implementations are fairly primitive, relying on simple mechanisms that clearly will not scale to thousands of peers. As JXTA matures, these systems could be enhanced with more scalable and robust mechanisms. The underlying abstraction JXTA provides is good, freeing application designers from the distractions of building their own mechanisms for discovery and for firewall traversal. The challenge is for the JXTA platform to implement these abstractions well, in a general purpose way suitable for the diverse peer-to-peer applications to come.

Nelson Minar was co-founder of Popular Power.


Return to OpenP2P.com

Copyright © 2009 O'Reilly Media, Inc.