Evaluating the Peer-to-Peer Model

The inevitable question is this: Can a peer-to-peer application perform better than a client-server application? Unfortunately, this question is not easily answered. It not only depends on the type of application, but on the type of peer-to-peer design, the number of users, and the overall traffic patterns. The most honest answer is probably this: There are some development niches in which peer-to-peer applications will perform better and require fewer resources. However, a peer-to-peer application can easily introduce new headaches and scalability challenges, which can't be dismissed easily. In order to create a successful peer-to-peer application, you must understand both the advantages and drawbacks of a peer-to-peer design.

Benefits and Challenges

Peer-to-peer applications hold a great deal of promise. Some of the unique properties of a peer-to-peer system are as follows:

A large network of peers will almost always have more computing resources at hand than a powerful central server.
A completely decentralized peer-to-peer application should have improved reliability because the server won't be a single point of failure for the system.
A peer-to-peer application should also have improved performance because there is no central server to act as a bottleneck.

Enterprise programmers have met some of these challenges by introducing server farms and clustering technologies. However, these solutions are expensive, and minor server-side problems can still derail an entire enterprise application.

On the other hand, the advantages of peer-to-peer applications are qualified by a few significant drawbacks:

As a peer-to-peer design becomes more decentralized, the code becomes more complex and the required network bandwidth to manage the peer discovery process increases. This might not be a problem if the bandwidth is spread out equitably over the network, but it often does become a problem in an intranet where the network must also be used for a critical client-server business application.
Although peer-to-peer systems don't rely on a central server, they do rely on the cooperation of multiple peers. This cooperating can be damaged by the variable connectivity of the Internet, where peers might abruptly disappear, even in the middle of serving a request. Similarly, in fully decentralized peer-to-peer systems, low-bandwidth clients can become "mini-bottlenecks" for their part of the network.
Peer-to-peer programming introduces significant challenges with network addressing due to the way the Internet works with dynamic IP addresses, proxy servers, network address translation (NAT), and firewalls.

It's also difficult to predict how a decentralized peer-to-peer solution will scale as the user community grows. Like all complex systems, a peer-to-peer network can display a dramatically different behavior at a certain "critical mass" of peers. Gnutella, a peer-to-peer protocol used for popular file-sharing applications, is in some respects an enormous in-progress experiment. As the network has grown wildly beyond what was originally expected, connectivity has suffered—frequently. At times, entire islands of peers have broken off from the main pool, able to communicate within their community, but unable to access other parts of the Gnutella network.

Ingenious techniques such as smart caching and optimized routing have been developed to meet the challenges of large peer-to-peer networks. However, it's still hard to predict how these solutions will play out on a large scale over a loosely connected network that might include hundreds of thousands of peers. These emergent behaviors are impossible to plan for. The only way to solve them is with an iterative process of development that involves frequent testing and updates. Ultimately, a peer-to-peer system may become more robust and perform better than a classic enterprise application, but it will take ongoing development work.

Peer-to-Peer and Security

Security is a concern with any type of application, and peer-to-peer systems are no exception. The key difference is that with server-based programming, the server is in complete control. If the server adopts rigorous privacy standards and security safeguards, your information is safe, and you're in a "benevolent dictator" situation. However, if the server falls short of its commitment in any way, you'll have no protection.

In a decentralized peer-to-peer application, peers lack the protection of the server. On the one hand, they're also free from monitoring and have control of their private information. It's difficult to track an individual peer's actions, which remain publicly exposed, but lost in a sea of information. Nevertheless, malicious peers can connect directly to other peers to steal information or cause other types of problems.

Doing away with a central authority is both liberating and dangerous. For example, a malicious user can easily place a virus in a file-swapping peer-to-peer application disguised as another popular type of application and infect countless users, without being subject to any type of punishment or even being removed from the system. In addition, the decentralized nature of peer discovery makes it difficult for an organization to enforce any kind of access control (short of blocking Internet access on certain ports). For these reasons, peer-to-peer application programmers need to consider security from the initial design stage. Some peer-to-peer applications handle security issues by allowing users to assign different levels of trust to certain peers. Other peer-to-peer systems rely on encryption to mask communication and certificates to validate peer identities. These topics are explored in Chapter 11, with cryptography, and Chapter 6, with code access security.

The Peer-to-Peer Niche

Peer-to-peer applications may not displace enterprise development, but they do tackle some increasingly difficult enterprise problems. Some of the scenarios for which a peer-to-peer design is well suited are presented in the next few sections.

Systems with Which Clients Need to Interact

The server-based model emphasizes one-way communication from the client to the server. That means that the client must initiate every interaction. This poses difficulty if you want to create a collaborative application such as a real-time chat, a multiplayer game, or a groupware application. With the introduction of a little peer-to-peer code, the problem becomes much more manageable.

Systems with Which Clients Need to Share Content

In the server-based system, everything needs to be routed through the central server. This taxes the computing power and network bandwidth of a small section of the overall network. Thus, you'll need a disproportionately powerful server to handle a relatively small volume of requests. If, however, the central server is used simply to locate other peers, it can become a "jumping off" point for a true peer-to-peer interaction, which is much more efficient. This is the infamous Napster model.

In some cases, you might use the file-sharing abilities of a peer-to-peer application to support other features. For example, some virus-scanning software packages use a form of file sharing to distribute virus catalog updates. In this model, an individual computer in an enterprise will download an updated virus catalog as needed. Other peers will then retrieve the update from the nearest local user, rather than the remote servers, thereby minimizing network traffic and the load placed on the central servers. Similar forms of resource sharing can support a variety of services, and in doing so they prove that peer-to-peer applications are about more than just swapping digital music.

Systems for Which a Central Server Would Be a Liability

This is generally the case if an application operated outside the bounds of local law (or in an area that could be subjected to future prosecution). For example, Napster, despite being partly peer-to-peer, required a central server for content lookup and for resolving peer addresses, and was thus subjected to legal intervention. Gnutella, a more radically "pure" peer-to-peer application, isn't vulnerable in the same way. Similarly, consider the case of the legendary remailer anon.penet.fi, which was forced to close in 1996 because the anonymity of users could not be guaranteed against court orders that might have forced it to reveal account identities. Pure peer-to-peer systems, because they have no central server, are impervious to censorship and other forms of control.

Systems That Would Otherwise Be Prohibitively Expensive

You could build many peer-to-peer applications as server-based applications, but you'd require a significant hardware investment and ongoing work from a network support team to manage them. Depending on the type of application, this might not be realistic. For example, SETI@Home could not afford a supercomputer to chew through astronomical data in its search for unusual signals. However, by harnessing individual chunks of CPU time on a large network of peers, the same task could be completed in a sustainable, affordable way. Another example is a virtual file system that can provide terabytes of storage by combining small portions of an individual peer hard drive. In many ways, these applications represent the ideal peer-to-peer niche.

Thus, peer-to-peer applications don't always provide new features, but sometimes provide a more economical way to perform the same tasks as other application types. They allow specialized applications to flourish where the support would otherwise not exist. This includes every type of peer-to-peer application, from those that promote collaboration and content sharing, to those that work together to complete CPU-intensive tasks.

A New Class of Application

Of course, new technologies always lead to a few new and radical applications that could not exist with earlier technologies. These applications may not grow and flourish right away—in fact, it's impossible to predict what next-generation software will be facilitated by peer-to-peer technology.

One possibility is real-time searching technology that allows peers to share any type of resources. The immense diversity of this content, and the variety of ways it can be described, make it impossible for a central server to catalogue it effectively. However, if a peer-to-peer application that uses an effective content-description query language could be designed, it could pass a specific, highly sophisticated request out to a wide audience of peers, who would then respond according to the highly specific information they have on hand. The way we share information on networks would be revolutionized overnight.

Another example of a new sort of application that might become possible with peer-to-peer is real-time collaboration software. Currently, collaborative applications allow for relatively simple tasks, such as exchanging text messages or sketching ideas on a primitive whiteboard. In the future, we could see peer-to-peer software tailored for a specific industry or activity. There could be a collaborative application that allows groups of users to work together on complex projects such as creating an architectural model, reviewing experimental data, or teaching a virtual lesson.^[2]

^[2]Microsoft's Windows Messenger includes a feature called Application Sharing, which allows users to collaborate in any ordinary application. However, a collaboration "killer app" would doubtlessly include some more insightful, specialized interfaces that would coordinate multiple users.