JXTA Chat, Sans Serverby Nelson Minar
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
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.
Pages: 1, 2