JXTA Chat, Sans Server
Pages: 1, 2
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:
- 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).
- A group is a collection of peers. A peer joins a group to
participate in a particular application.
Chat tutorial: Everyone joins one group.
- A service is a capability running inside a peer group. The
service may be running on all peers, or just a few within the
Chat tutorial: Every peer runs a chat client service. In addition, one peer runs a chat server service (except in the decentralized case).
- 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.
- 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.
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.
|Talk about your own experiments with JXTA here.|
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.
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.
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.
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