|
|
A Look at Simple P2P Architectures
Posted On July 7, 2004 by Madhu AP filed under Enterprise , Internet
A peer-to-peer application is different from the traditional client/server model because the applications involved act as both clients and servers. That is to say, while they are able to request information from other servers, they can also act as a server and respond to requests for information from other clients at the same time. This approach increases the amount of value that each node on the network can add because it not only takes information from a source, but it also has the ability to share that information with other sources. A typical peer-to-peer application has the following key features that help define it:
Discovering other peers: The application must be able to find other applications that are willing to share information. Historically, the application finds these peers by registering with a central server that maintains a list of all applications currently willing to share and giving that list to new applications as they connect to the network. However, there are other means available, such as network broadcasting or discovery algorithms.
Querying peers for content: Once these peers have been discovered, the application can ask them for the content that is desired by the application. Content requests often come from users, but it is highly conceivable that the peer-to-peer application is running on its own and performing its query as a result of some other network request that came to it rather than a specific request made by a user at that machine.
Sharing content with other peers: In the same way that the peer can ask others for content, it can also share content after it has been discovered.
There are a number of design options to consider when designing a peer-to-peer application. The decisions you make about the architecture for your peer-to-peer application will have a significant impact on the type of features that your application is able to offer and, therefore, the experience that your users will have when using your app.
Pure P2P
A pure peer-to-peer application has no central server whatsoever, as you can see in Figure 1. It dynamically discovers other peers on the network and interacts with each of them for sending and receiving content. The strength of this type of application is that it does not rely on any one server to be available for registration of its location for other peers to find it. At the same time, the lack of a central discovery server poses a problem because a relatively low number of clients can be discovered, thereby limiting the application’s reach. In this scenario, a peer can either use information from a local configuration scheme to discover the clients (for example, a configuration entry that tells it who to talk with) or it can employ network broadcasting and discovery techniques such as IP multicast to discover the other peers.
non-multicast schemes are used to discover the peers. In this case, the applications use some other scheme such as a well-known node approach, where each peer knows about at least one other peer and they share this knowledge with other peers to form a loosely connected mass of nodes.
P2P With a Simple Discovery Server
Using IP multicast can be problematic since it is not widely deployed on the Internet, but it can be useful in intranet scenarios where the network is more controlled and infrastructure required for multicast is known to exist. Pure peer-to-peer is also being deployed on the Internet in cases where non-multicast schemes are used to discover the peers. In this case, the applications use some other scheme such as a well-known node approach, where each peer knows about at least one other peer and they share this knowledge with other peers to form a loosely connected mass of nodes.
In many cases, it is easier to make this solution scale better than the pure peer-to-peer option because it circumvents the issues of discovery by requiring only one request to the central server. Note that it is possible to make pure peer-to-peer solutions scale extremely well, but if you are able to rely on a server for some of the basic tasks (like discovery), high scalability can be achieved with a lower cost in terms of development time. However, this approach hinges on the availability of the central server. If the central server is not available, the peer-to-peer application will not be able to find other peers.
In addition, requesting content from each individual peer can be quite expensive from a network resource perspective. This may not seem like a big deal if you’re thinking about a few peers interacting over a network, but if your app is being written for use over the Internet or a large enterprise environment, this consideration suddenly becomes much more significant, scaling factorially.
P2P With a Discovery and Lookup Server
This model, extends the discovery server so that it also includes content lookup services. In this case, the peer application not only registers with a discovery server, but also uploads a list of its contents at regular intervals. When an application is looking for a particular content, it queries the central server rather than sending a query to each client. The central server then responds with a list of the clients that contain the requested content and the peer application can contact those clients directly to retrieve the content.
Quite often, this approach will scale better than the previous options because it reduces the number of queries going over the network (arguably one of the scarcest resources). However, this saving will incur a cost on the server. Servers are now more involved in the process of content sharing and the peer’s demands will use significant resources.
P2P with a Discovery, Lookup and Content Server
Just to show that this can actually come full circle, a system can be designed so that the peers can upload the content to the server as well, if you so choose . This approach effectively becomes the client/server model because the peers are no longer contacting other peers for content. Each peer registers with a server (if needed), queries it for information and transfers any desired content down from the server. The problem with this approach is that when content is downloaded from all of the clients, the server quickly becomes the bottleneck and is easily overwhelmed by the peers (clients).
To put this into perspective, consider a peer-to-peer application that shares video content. Let’s assume the application supports up to 1,00,000 peers, each containing megabytes of data. The total amount of content available to any one peer can quickly reach hundreds of terabytes. While server capacity can always grow, placing such demand on the server can be costly and can create a significant number of bottleneck and reliability issues on the network. Placing all of the demand on the server also means that the substantial resources available on the clients that would be utilized in the peer-to-peer model are potentially wasted in the client/server model.