Peer-to-Peer Style
4.5.1 Overview
In the peer-to-peer style of the C&C viewtype, components directly interact as peers by exchanging services. Peer-to-peer communication is a kind of request/reply interaction without the asymmetry found in the client-server style. That is, any component can, in principle, interact with any other component by requesting its services. Thus, connectors in this style may involve complex bidirectional protocols of interaction, reflecting the two-way communication that may exist between two or more peer-to-peer components.
Examples of peer-to-peer systems include architectures that are based on distributed object infrastructure, such as CORBA, COM+, and Java RMI. Runtime architectural views of object systems, using notations such as collaboration diagrams, are often examples of this C&C style. Note, however, that a system designed in a non-peer-to-peer style could be implemented using object-based implementations and a distributed object/component infrastructure.
4.5.2 Elements, Relations, and Properties
Table 4.5 summarizes the discussion of the characteristics of the peer-to-peer style. The component types in this style are peers, such as objects, distributed objects, and clients. The principal connector type is the invokes-procedure connector. Unlike client-server, the interaction may be initiated by either party. Peers have interfaces that describe the services they request from other peers and the services they provide. The computational flow of peer-to-peer systems is symmetric: Peers initiate actions to achieve their computation by cooperating with their peers by requesting services from one another.
| Elements |
Component types: peers. Connector types: invokes procedure. |
| Relations | The attachment relation associates peers with invokes-procedures connectors and determines the graph of possible component interactions. |
| Computational model | Peers provide interfaces and encapsulate state. Computation is achieved by cooperating peers that request services of one another. |
| Properties | Same as defined by the C&C viewtype, with an emphasis on protocols of interaction and performance-oriented properties. Attachments may change at runtime. |
| Topology | Restrictions may be placed on the number of allowable attachments to any given port, or role. Other visibility restrictions may be imposed, constraining which components can know about other components. |
Constraints on the use of the peer-to-peer style might limit the number of peers that can be connected to a given peer or impose a restriction about which peers know about which other peers. The form of data may be a reference or a value. The propagation of requests from peer to peer can also be constrained.
4.5.3 What the Peer-to-Peer Style Is For and What It's Not For
The peer-to-peer style presents a view of the system that partitions the application by area of collaboration. Peers interact directly among themselves and can play the role of both clients and servers, assuming whatever role is needed for the task at hand. This partitioning provides flexibility for deploying the system across a distributed system platform. Because peers have access to the latest data, the load on any given component acting as a server is reduced, and the responsibilities that might have required more server capacity and infrastructure to support it are distributed. This can decrease the need for other communication for updating data and for central server storage but at the expense of storing the data locally.
Peer-to-peer computing is used in distributed computing applications. Using a suitable deployment, the application can make efficient use of CPU and disk resources by distributing computational-intensive work across a network of computers and by taking advantage of the resources available to the clients. The results can be shared directly among participating peers.
4.5.4 Relation to Other Styles
The absence of hierarchy means that peer-to-peer systems have a more general topology than client-server systems do.
4.5.5 Examples of the Peer-to-Peer Style
The Gnutella open source project provides software registered under the GNU License to support bidirectional information transfer using the peer-to-peer style. The topology of the system changes at runtime as users enter the system or change their connections. A user becomes a Gnutella site by installing Gnutella software that functions as a peer in the Gnutella system. A user configures the software to communicate directly with a small number of sites belonging to friends or with public Gnutella sites; these are its peers.
Gnutella supports protocols for peers to discover other peers, to search for information, and to exchange information. The Gnutella protocol among peers for obtaining information uses HTTP and is based on request and reply. If a Gnutella site A requests information from one of its peers B, that peer will respond with any information of interest. It will also pass the request to its peers, keeping a record of the request. When its peers return with information, B knows to return it to A. One property of the request is whether the information or its source is returned. Clients have the option of setting this property so that a source is returned if information might be a large piece of data. The requestor then could initiate a data exchange directly with the source through another protocol, such as client-server.
Figure 4.4 shows a small Gnutella system of four peers. The figure shows the configuration of the system, but not its behavior.
Figure 4.4. A system in the peer-to-peer style. B is a peer of A, while C and D are peers of B.