P2P Programming in Java

The Peer-to-Peer Model

Peer-to-peer (P2P) encourages users to share their resources with others; resources include hard-disk storage, CPU time, and files (audio, video). This is different from today's Web/Internet in which business/government/university servers present information, and the rest of us read it. The difference is illustrated by Figure 29-5.

Figure 29-5. Client/server versus P2P

P2P isn't a new idea: the early Internet (at that time, the ARPANET) was designed to be P2P so U.S. universities and government installations could share computing resources.

Many of the killer apps of the 1980s, such as Telnet and email, were client/server-based but their usage patterns were symmetrici.e., most machines ran clients and servers. Usenet (net news) is a P2P application: it employs a decentralized file-sharing model for distributing news, but an unofficial backbone has developed over time, based around server inequalities in storage capacity, processing speeds, and network connectivity.

Things started to change with the growth of the Web. It's a client/server model like most of the earlier applications, but differences lie in its political and social components. Most users only browse the Web; they don't run their own web servers. This is due to the user's lack of technical knowledge, the difficulty of setting up a server, and because commercial ISPs prohibit server installation. Many ISPs allocate dynamic addresses only to clients, making the running of servers impossible, and impose firewall restrictions that only permit web-page access. Broadband connections, such as cable modems, offer asymmetric bandwidth, which makes the serving of material slow.

The restrictions on users (e.g., firewalls) are recent, triggered by the lack of accountability mechanisms in the IP: the protocol lacks technological barriers to stop users sending spam and attacking machines. Its designers made the fatal assumption that users are responsible. The problem is sometimes called the Tragedy of the Commons: a commonly owned resource will be overused until it degrades, due to its users putting self-interest first.

The issue of accountability has led to better support for cryptography in IPv6 and experimental technologies such as micropayments and reputation schemes.

With micropayments, a person wishing to use someone else's resource (e.g., one of their files) must compensate that person in some way. This might be in the form of digital money or another valuable resource. Micropayments have the benefit of solving many forms of hacker attack, such as spam and distributed denial of service (DDoS), since hackers must pay an excessive amount to flood the network with their datagrams.

A reputation scheme typically requires a respected user to verify the reliability of a new user. This idea is well-known in Java, which utilizes encrypted signatures and third-party verifiers to identify trusted JAR files and applets. Some of the technicalities are explored in Appendix B, where I consider how to sign files that are downloaded and installed using Java Web Start.

Many P2P systems are concerned with anonymity to prevent external agencies knowing who is in a P2P group, where files are stored, and who has published what. These aims make accountability and trust harder to support.

Part of the drive behind these P2P features was the fate of Napster, which was closed down because it published music files that it hadn't authored. Napster could be targeted because it was a hybrid of P2P and client/server: a Napster server stored details about who was logged on and the published files. Unfortunately, this is a common situation; most current P2P systems require some server capabilities. For instance, games must validate new players, maintain account information, supply current status information for the game, and notify other users when a player joins or leaves.

Pure P2P has the advantage that there's no central point (no server) whose demise would cause the entire system to come crashing down. This makes P2P resistant to attacks such as DDoS and legal rulings!

The main drawback of pure P2P is paradoxically its lack of a server, which makes it difficult to control and manage the overall application. With no server, how does a new user discover what's available?

The P2P diagram in Figure 29-5 suggests that participants use broadcasting to communicate, but this approach soon consumes all the available bandwidth for reasons outlined earlier. Large-scale P2P applications use IP multicasting with UDP packets, which currently relies on the MBone, a virtual overlay installed on the Internet to facilitate multicasting. A special pseudo-IP address, called a multicast IP address or class D address, is employed, which can be in the range 224.0.0.0 to 239.255.255.255 (though some addresses are reserved).

Multicasting avoids the potential for loops and packet duplication inherent in broadcasting since it creates a tree-based communication pattern between the multicast group members. Java supports IP multicasting with UDP.

JXTA provides core functionality so that developers can build P2P services and applications (see http://www.jxta.org/). The core JXTA layer includes protocols and building blocks to enable key mechanisms for P2P networking. These include discovery, transport (e.g., firewall handling and limited security), and the creation of peers and peer groups.

The JXTA specification isn't tied to any particular programming language or platform/device. Its communication model is general enough so that it can be implemented on top of TCP/IP, HTTP, Bluetooth, and many other protocols. Currently JXTA utilizes Java; it was initiated at Sun Microsystems by Bill Joy and Mike Clary. A good site for finding out about P2P is O'Reilly's http://www.openp2p.com/.