Scalability of Peer-to-Peer Systems

Transcription

1 Scalability of Peer-to-Peer Systems Jari Mäntylä Helsinki University of Technology Abstract In recent years, peer-to-peer systems have been widely deployed in the Internet. This is because of the improved availability of information and the control it offers to the users. Users have the latest information always at hand. Since the peer-to-peer systems tend to be so popular, scalability becomes an utterly important feature in these architectures. Many algorithms have been developed to address this issue and they get there by slightly different means. Earlier protocols were unstructured and had poor scalability, whereas modern peer-to-peer systems are structured and scale well. However, the second generation basically supports only exact-match queries, instead of keyword searching found in the first generation systems. This paper introduces four existing algorithms (i.e., Gnutella, Tapestry, Pastry and Chord). Gnutella represents the first generation systems, whereas the rest belong to the second generation. We compare these two generations in relation to scalability in a qualitative fashion. In addition, we present improvements how these systems could be ennobled in relation to scalability. In the case of Gnutella, there seems to be many ways to improve its scalability, which in fact might prolong its existence despite the more advanced second generation. Whereas, the second generation is still young, and there are only few improvements and propositions submitted by the research community. KEYWORDS: peer-to-peer, scalability, Gnutella, Tapestry, Pastry, Chord. 1 Introduction Peer-to-peer systems typically consist of large number of heterogeneous, distributed and dynamic network nodes (e.g., PC, router, PDA etc.). This arrangement presents many challenges for distributed applications to cope with in a large scale environment such as the Internet, where failure-prone peers join and exit the network continuously. As a consequence, we need a sophisticated mechanism to perform effective queries and stabilizations, which uphold the integrity of the overlay network. In this paper we focus on the scalability issue of a few algorithms used for data discovery and organizing tasks in peer-to-peer systems. Specifically, we will make a comparison of scalability in Gnutella, Tapestry, Pastry and Chord. Gnutella was chosen because of its open architecture and wide adoption in the Internet. There s also a lot of debate around Gnutella. The latter three were chosen to represent the second generation of structured peer-to-peer overlay infrastructures. These systems act as a substrate for peer-to-peer applications. Generally speaking, scalability can be defined as the adaptability to changes in the peer-to-peer system size, load extent and nature of the load [1]. On the other hand, this paper focuses on the scalability of the system in relation to both search and stabilization algorithms. Also, congested peers are taken into account while comparing the scalability. That is, the network load should be distributed evenly among the peers, which means that every peer should be aware of approximately the same number of other peers. The aforementioned algorithms are based on a virtual topology, or in other words, on an overlay network, which is generated on the application layer above the operating system s network layer. This overlay system is used for routing or forwarding the lookup and maintenance messages between the peers. Structured overlay networks allow the system to self-organize in a fairly dynamic environment, where peers constantly enter and leave the network either willingly or because of failures. Structured overlay networks typically offer a horizon for lookup-time. This paper makes solely a qualitative comparison no simulations or complex arithmetic evaluation is included. Rest of the paper is divided into four Sections. In Section 2, we will describe the named overlay networks in detail. Following the details is the actual comparison (Section 3) of the algorithms properties in relation to scalability defined earlier. The scalability of these systems could also be improved with new ideas. We are presenting a few proposals made by other research groups in Section 4. Finally, we will make conclusions of the comparison (Section 5). 2 Algorithms 2.1 Gnutella Overview Gnutella [6, 5] is one of the first-generation fully distributed peer-to-peer file sharing protocols. It does not rely on any central server. On the contrary, it consists of number of equal nodes, which all act as both the peers and the servents. In other words each of these nodes acts as the client (i.e., consumer of the information) and the server (i.e., distributor of the information). Gnutella protocol is fairly simple. Therefore, it has widely spread into today s Internet as an abundant set of file sharing applications.

2 2.1.2 Message types Gnutella operates on an overlay network that provides routing and forwarding of messages between the nodes. The messages consist of a few types: Ping, Pong, Query, Query Hit and Push. The first pair of these is used to attach a node to an existing Gnutella network. Existing nodes reply to the joining node s Ping-message with a Pong-message. Similarly, the nodes reply to the Query-message with a Query Hit-message, if their file database contains queried information. The last message-type (Push) is used in situations where peers with the wanted information do not allow incoming connections (e.g., ones that lie behind a firewall) Routing Routing in Gnutella is based on flooding or constrained broadcasting. Generally speaking, every message received by a node is forwarded to all of its neighbors. Only exception is the node from which the message arrived. Every message contains a Time To Live-header (TTL). This value is decremented by one after each hop until it reaches zero, when it s no longer forwarded. Pong- and Query Hitmessages travel the same route as the corresponding Pingand Query-messages, but in the opposite direction. Also, Push-messages are sent along the same path that the corresponding Query Hit-message traveled. Each message carries an ID field that marks the message with unique identifier. Whenever a node receives a message with same type and ID encountered in the past, it discards the message. An example of Gnutella topology is shown in the figure 1. unique identifier (GUID), which is selected likewise at random from the same identifier space as the nodeids. These IDs are presumed to be evenly distributed throughout the entire identifier space. This is achieved by using an appropriate hashing algorithm (e.g., SHA-1). In additions to the nodeid or GUID, a message contains an application-specific identifier A id (having the same role as a port has in transmission protocols), to support co-existence of different applications Routing Tapestry [11, 12] maps each identifier G to a solitary live node (nodeid), which is called the root G R of the object. A node maintains a routing table consisting of nodeids and corresponding IP addresses. These nodes are called the neighbors of the local node. Routing is carried out using only node-local information by forwarding a message to a node progressively closer to the G R by determining which of the neighbors has a matching prefix. Progressive in this context means routing closer to the target ID digit by digit (i.e., Hexadecimal digit of the identifier). The routing table is divided into multiple levels, each level i consisting of nodes having i 1 matching prefix digits their nodeid. To sum up, each routing hop takes the message closer to the destination node by at least one digit. The algorithm outlined above yields that message is routed to an existing node with O(log β (N)) hops (where N is number of the nodes in the network and β the base of the identifier space). Tapestry takes locality into account in its design. This is achieved by selecting the closest possible node (i.e., shortest network distance) to fill the slot in the routing table. An example of Tapestry routing is shown in the figure 2. Figure 1: Gnutella: An example of the Gnutella neighborhood topology. 2.2 Tapestry Overview Tapestry is an overlay infrastructure that offers decentralized object location and routing (DOLR). Tapestry nodes are assigned a nodeid that is allotted randomly from a large uniform identifier space. One physical host can host multiple nodes. Application-endpoints, objects utilized by applications acting on top of Tapestry, are assigned a globally Figure 2: Tapestry: Path of the message to node 42AD originating from node L1, L2, L3 and L4 emphasize the number of matching digits (minus one) between the two nodes Object publishing Each object O (with GUID O G ) is separately published in the network by the server S storing a copy of the object. This is done by routing a publish message periodically to the object s root node O R. Each node in the path stores a link <O G, S> in their pointer map. Whenever a client wants to locate an

3 object O, it routes a message to O R. Every node in the path checks whether they possess a pointer mapping to O. If they do, they forward the message to the S directly. Otherwise, the message is forwarded a step closer to the O R. An example of Tapestry object publishing is shown in the figure 3. nodeids are diverse in physical location and available resources. The identifiers have a base 2 b, where b is the number of bits per one digit. Typical value for b is 4, which results in hexadecimal digits Routing Figure 3: Tapestry: Two replicas of object 4378 are published to their root node Each node along the path to the root node stores a location pointer to the object Node insertion and deletion Every joining node has a surrogate node S (i.e., the root node to which the N id maps in the current network). The insertion process is started by S, which finds the largest matching prefix (length p) that N id and S id share. S then sends an Acknowledged Multicast message to all existing nodes having the same prefix. These nodes contact N and become the basis of the neighbor set of N. With the help of this set, N constructs its routing table in an iterative manner by starting from level p and decrementing it by one in each step. Here it decides which nodes to include by favoring locality or the network distance between them. Also, each node contacted by N update their routing table with N wherever appropriate. A node can leave the Tapestry network voluntarily or involuntarily (e.g., regular failure in the wide-area network). If the node N has a chance to leave in collaboration, it informs a set of nodes in its backpointers by sending them a replacement node to place in their routing tables. At the same time all the informed nodes republish their objects through N and its replacements. The departure may occur ungracefully and many times in a short interval. This is addressed by keeping backups for each routing table entry and object in pointer mappings. Nodes poll the network to detect link failures and start a repair process for routing tables and object publications if necessary. Messages are routed to a live node whose nodeid is numerically closest to the given key. Similarly to Tapestry, Pastry uses prefix-based routing. One hop in the routing process usually takes the message one digit (i.e., b bits) closer to the destination node s nodeid. A node upholds three discrete set of nodes: routing table, neighbor set M and leaf set L. The routing table consists of log 2 b(n) rows (i.e., number of digits in the nodeid), each having 2 b 1. Each entry on row n has common prefix with the local node till nth digit. Nodes are selected considering locality (i.e., network proximity metric). The neighbor set contains M nodes that are closest to the local node according to network proximity. The leaf set contains L nodes whose nodeid is numerically closest to the local node s nodeid. The neighbor set is not used in the routing, whereas the leaf set is. Typically, M and L have the value of 2 b or 2 b+1. A node forwards given message preferably to a node in the leaf set whenever it falls within the range of their nodeids. Otherwise, the message is forwarded to a node in the routing table whose nodeid shares one digit longer prefix than the local node. The appropriate slot in the routing table may be empty or the actual node unreachable, in which case the message is forwarded to a node sharing a prefix of at least the same length than the local node one that is numerically closer to the message s key. An example of Pastry node is shown in the figure 4 and a routing example is shown in the figure Pastry Overview Pastry [13] is a substrate for a variety of peer-to-peer applications. Again, the nodes are assigned a unique identifier nodeid randomly from a circular identifier space, that ranges from 0 to This randomness leads to a uniform distribution of the identifiers in the space. If the nodeid are obtained by hashing IP address or public key, the close-by Figure 4: Pastry: An example node All the numbers are in base 4 (b = 2). The routing table cells are split with - to emphasize the common prefix, next digit and the rest of the nodeid.

4 did, Chord assigns nodes a key through consistent hashing, which tends to balance the load (i.e., nodes have roughly the same number of keys assigned to them). The identifiers lie on an identifier circle (i.e., Chord ring). Every key k maps to single node whose identifier is equal to k or is the next node that succeeds it (clockwise). That node is called the successor of k. If identifier has a length m (bits), there are 2 m possible values on the ring Routing Figure 5: Pastry: Path of the query to key d46a1c initiated by node 65a1fc Node insertion and deletion A new node acquires its nodeid X (e.g., by a hashing algorithm mentioned in chapter 2.2.1). N asks a formerly attained node nearby with nodeid A to route a message with key X. The message ends up in a node with nodeid Z, which is numerically closest to X. All of the nodes encountered on the path to node Z send their state tables to X. The new node can then initialize its neighbor set with A s neighbor set and leaf set with Z s leaf set. Routing table is filled with entries found from the routing tables received from the nodes on the path from X to Z. Simplified, the ith row in the routing table is initialized with N i s (i.e., ith node on the path) ith routing table row. After this initialization, X sends its formed state to each node found in its routing table, neighbor set and leaf set. Those nodes then have the opportunity to update their tables according to the received information. In the case of node failure, a replacement is to be found for it in the tables. If a node in the leaf set fails, the local node asks the remaining leaf nodes (either the lesser or the greater half, according to failed node s id) for their leaf set and finds an appropriate replacement. The neighbor set is repaired in a similar manner by finding a replacement from living neighbors sets. A failing routing table entry is repaired by contacting another node on the same row and asking for its entry. If none of the nodes on the same row has a proper entry, the procedure continues by asking the nodes on the next row. In theory, a replacement is always found for each failing entry in the state tables. 2.4 Chord Overview Chord [16, 17] is described as a peer-to-peer lookup protocol. In fact, it provides only one operation: mapping a key onto a node. It is application-specific, how the key is used (e.g., the node on which the key maps, might store an item corresponding to that key). Likewise, as Tapestry and Pastry Every node sustains a maximum of m routing entries. A node s (identifier n) ith entry in the routing table points to successor of key n+2 i 1. This is called the ith finger of the node n. This definition yields that every node maintains a routing table of size log(n). Every node keeps also track of its immediate predecessor (i.e., the next node counterclockwise). Logically, the first finger of the node is its successor. On the other hand, the last finger is at least halfway across the circle; hence the routing quickly approaches the destination. When routing a key k the local node n checks if k falls between n and the successor of n. If so, it returns the address of the successor and the routing is complete. Otherwise, the node finds a finger that most immediately precedes k and asks that finger node to continue routing. This procedure completes within log(n) hops. Example of Chord s finger table is shown in the figure 6. Also, a routing example in that setting is shown in figure 7. Figure 6: Chord: Finger table contents for node Node joins and stabilization A node joins the network by asking another node to route its identifier n on the network, which yields its successor n s. At the same time, node with id n s acquires n as its new predecessor. Next time the joining node s predecessor n p checks if it is its successors (used to be n p ) predecessor, it finds out that actually node n is its successor. Node n p also informs node n that it is the predecessor. After the successor (and predecessor) pointers are correct, the newly joined node finds its fingers by routing the keys n + 2 i 1, where i is [1,m]. The fingers are not required to be specified for the routing procedure to work correctly.

5 3.1.1 Overlay topology Figure 7: Chord: Path of the query for key 54 initiated by node 8. Stabilization procedure utilizes partially the same set of functions as the joining. Nodes periodically check whether they are their successor s predecessor. This way node n p finds out about newly joined node n emerged in between n p itself and n s. Nodes also notify their successor of themselves, and the successor might update its predecessor pointer accordingly. Nodes clear out their predecessor pointer if a periodic check fails (i.e., the predecessor does not acknowledge). Nodes maintain the integrity of their finger table by routing to keys n + 2 i 1 periodically. This way they discover the newly joined nodes to be used as new valid fingers and revise their finger table. 3 Comparison General properties of the aforementioned peer-to-peer systems are listed in the table First generation Gnutella is less of a substrate than the other aforementioned protocols, since it basically provides only file sharing services in addition to overlay network maintenance. Gnutella belongs to the first generation of peer-to-peer systems that are based on unstructured overlay networks. It is old-fashioned mainly because of its flooding-based search and maintenance algorithms. This flooding or constrained broadcasting can be described as best effort within specified range, since the message is propagated everywhere within predetermined scope. One message is processed and sent several times during the forwarding procedure. This consumes peers CPU time and network resources even if they were otherwise passive. Time To Live -parameter (TTL) affects significantly the cost of querying and discovering of peers. Increasing it improves the query hit ratio and number of new peers detected, but at the same time it hugely raises the number of messages propagated throughout the network. Portmann et al. [6] state that the topology of Gnutella overlay network affects the scalability significantly. They measured through simulations the total cost of search and peer discovery mechanisms in three different topologies (i.e., Mesh, Random and Power-law). These topologies differ very much in their nature. The simulated topologies had a common node degree of about 4, which means the average number of neighbors each node maintains. Their results indicate that the cost of searching in Gnutella network with power-law topology is substantially lower than in the other topologies. The least load is imposed on the nodes in the power-law topology, where the distribution of the node degrees is decaying according to a power function. Developers should have proper knowledge about this topology issue when implementing Gnutella-based applications. In reality, it has been shown that the Internet and Gnutella network topologies have a power-law property ([3, 5]). Nevertheless, in our opinion, this can make the co-operation of Gnutella applications obscure, since different implementations might address this in a different way through various configuration parameters Congestion Neither does Gnutella take into account the congested peers. Gnutella network functions correctly until part of the nodes become congested and cannot perform necessary processing and forwarding of the arrived messages due to the lack of proper CPU and network resources. Portmann et al. [6] show that Gnutella does not function well as the number of peers becomes thousands. Furthermore, the network gets fragmented and queries do not get satisfied properly. In fact, we should be talking about tens or hundreds of thousands of nodes since there are millions of potential nodes in the case of the Internet. Therefore, one can state that Gnutella does not scale well enough to be used in the ever-growing Internet. Besides, none of the text above considers the file transfer part, which as well affects the congestion among the peers. 3.2 Second generation The other protocols (i.e., Tapestry, Pastry and Chord) belong to the second generation of peer-to-peer systems. This generation is based on Distributed hash tables (DHT), which basically means distributing of the information to multiple locations. In fact, these systems are only a substrate for peer-topeer applications. They provide an overlay network, which offers efficient object location with small horizon (i.e., small number of hops) and agile node insertion and network stabilization services. Many kinds of applications can be built on these systems; ranging from distributed file storage to decentralized instant messaging. These systems are not as easy to implement as for example Gnutella. Even so, application developers are able to use existing reference implementations of these open architecture systems, which makes it all a softer job. Unlike Gnutella, these second generation systems guarantee content location, but at the same time require exact-match queries. Keyword search implementation on top of these

6 Lookup Maintenance Routing table size Gnutella variable variable number of neighbors Tapestry O(log b (N)) O(log b (N)) b log b (N) Pastry O(log 2 b(n)) O(log 2 b(n)) (2 b 1) log 2 b(n) Chord O(log 2 (N)) O(log 2 2 (N)) log 2 (N) Table 1: Here are listed a few properties of the protocols presented in chapter 2. N is the number of nodes in the network and b is a configuration parameter of Tapestry and Pastry. [2] DHT-based systems is not a trivial task, since the exactly same file might have different names on different nodes. Keyword searching is mainly based on the filenames, but some sort of meta information coupled with the file could be of help there. The gained advantages in routing performance and scalability come with this exact-match limitation. In our opinion, this narrows the application deployments at least partially in reality, since file sharing is the most utilized feature Structured overlay networks These systems use key-based routing (KBR), which is common for all structured peer-to-peer algorithms. As a common feature, all of these use only local information in routing, which has a positive impact on scalability, as the route information is not propagated throughout the overlay network Resilience Structured nature does not come for free there is a cost of stabilizing and maintaining the integrity of this network. While Gnutella uses heartbeat messages to determine whether its neighbors are alive, these more sophisticated systems stabilize the network both periodically and upon detecting a failure. Still, stabilization demands a lot of messages to be propagated down the hierarchy. For example, a node in Chord needs to send O(log 2 (N)) messages when either joining or leaving the network [16]. Designers have used simulations to prove their overlay network to normalize or recover rather quickly even under major breakdowns. Nevertheless, these systems recover as well as first generation of the systems do. Xuan et al. [18] claim that Chord has less maintenance overhead than most of the other DHT-based peer-to-peer protocols. At the same time, they admit Chord being most fragile against malicious nodes Locality Tapestry and Pastry take network distances into account while building their overlay topology. Chord in its basic form does not consider this; hence given overlay hop might span the entire diameter of the underlying network. Locality should be addressed by all of the systems, as it affects the efficiency of the message forwarding between adjacent nodes in the overlay topology. Also, this effect accumulates as network grows. Using locality speeds up the message propagation; hence improving the overall performance of the system. On the other hand, for example in Pastry [13] locality preference together with major breakdowns tends to produce another problem: creation of multiple isolated self-organizing overlay networks, unaware of the others. This isolation might persist even after complete recover from the breakdown. Rowstron et al. propose random use of IP multicast as a solution. In our opinion this sounds too complicated mechanism that would need special multicast configuration. Also, IP multicast might be unavailable in parts of the network. Instead, as mentioned before, Chord does not consider locality and is therefore quite resilient against this partitioning. This is a two-sided problem, which requires a research of its own Routing Tapestry and Pastry both use prefix routing while Chord uses the numerical difference between current node and the destination. Both of these methods deliver the message to its destination with the same horizon O(log(N)). All of these systems are able to forward a message to its destination even under failures. All of them have some sort of backup for the nodes in their state tables which are used upon failures. Tapestry and Pastry node forwards the message numerically a little closer to the destination whenever it is not able to bring it a digit closer, as it normally would. Whereas Chord forwards the message to its immediate successors (or one of them in the case of successor list) if the appropriate finger node fails to respond. As a consequence, these networks are rather resilient, even in the case of massive failures that are quite common in today s Internet Congestion Structured networks employ consistent hashing to accomplish an even distribution of the nodes and objects identifiers in the identifier space. This deconcentration addresses the issue of congestion as the load is presumably evenly divided among the peers. Since these systems map a key to a single node by default, certain nodes with popular objects might get congested. One possible solution to this is replication. For example PAST [14], a file sharing utility built on Pastry, stores file replicas on a set of nodes whose size is determined by taking the rate of transient nodes into account. Tapestry [12] also provides a replication feature indirectly. Each node storing a replica or a link to one publishes this as an object on its own. Tapestry s design causes the queries of an object to arrive at a near-by node with a replica of this object. While on the contrary, Chord [17] does not provide replication but leaves this to application developers. In our opinion, Tapestry s way of publishing each replica is the most practical way. Other solutions possibly require nodes to copy the replicas from one node to another without users

7 explicit approval. 4 Discussion Many of these aforementioned protocols have unattractive features that could be bypassed by upgrading or extending the default specifications. Next, we are going through some previous researches addressing these weaknesses. As Gnutella is the most deployed and analyzed among the described protocols, these proposals tend to be bound to it. 4.1 Gnutella Chawathe et al. [9] and Singla et al. [10] propose the concept of supernodes or ultrapeers for Gnutella networks. Ultrapeer is a node with significantly more network resources than regular nodes participating in the system. Ordinary nodes send information about their shared data to these ultrapeers that are then responsible for receiving and processing all of the queries in the network. Singla et al. suggest that leaf nodes form overlay network connections only to the ultrapeers, which should reduce messaging and traffic in overall between the leaf nodes. In our opinion, this contravenes the idea of peer-to-peer networks, where all of the peers should share identical functionality. If these ultrapeers are considered, the whole concept is moving to a hybrid direction, where things are not completely decentralized. Sripanidkulchai et al. [4] propose an idea of internetbased locality where queries exploit common interests of certain group of peers. In other words, if some peer finds out another peer has information that it has interest in; it is very likely that this peer has also other attractive material available. In the case of Gnutella, the proposal is based on shortcuts that form a loose structure on top of the unstructured overlay. Their proof and analysis seems logical. Therefore, we hope to see real life implementations and research in relation to this proposal. Sripanidkulchai et al. also state that these shortcuts improve the query performance of Chord. In our opinion, the presented evidence was too slight to convince us it would be worth the effort. Markatos [7] and Patro et al. [8] suggest that peers should cache the query results it has seen in the past. This idea is based on the assumption that real life queries show extreme amount of locality, which certainly favors this idea. He shows that caching for even a short period of time increases query performance significantly. He also shows that cache does not consume a lot of memory and thus is obtainable on each node s host. Query performance affects directly the scalability, since fewer messages gets flooded through the network. We hope this idea gets deployed widely, as it convinced us about improving the scalability of Gnutella. Furthermore, this caching can be done transparently. That is, every node is not required to cache the results, since the actual results do not differ whether caching is used or not. Randomizing Gnutella s flooding mechanism, so that a node forwards the query only to subset on its neighbors, improves the scalability but tends to favor only popular content. It probably would result in multiple adjacent queries with same keywords, if users knew about the random behavior. Hence, this is not the candidate solution for improving Gnutella s scalability as a whole. 4.2 The second generation optimizations Zhang et al. [15] propose two optimizations for structured overlay networks that exploit the routing table redundancy. They experimented these optimizations with Pastry, which has potentially a lot of routing table redundancy because of its fault-resilience design. In more detail, each entry in the routing table contains more than one node that could be used as a backup in the case of failures or in the routing table maintenance to lower the delay caused by overlay hops by making the closest node the primary choice. Normally the routing table redundancy is exploited in the case of failures, but they could be used to optimize routing as well. Their first proposal is to check whether one of the backup entries is in fact the exact destination of the query. In that case, the message could be forwarded directly to its destination. Their second proposal is more probabilistic as it includes some probability calculus in regard to the average distance between adjacent nodes in the identifier space. Even though one of the backup entries might not have the exact same identifier as the queried key, it might still be the actual destination. Zhang et al. [15] introduce a constant c, which is used to determine whether one of the backup entries is the destination with high probability. If the distance between the queried key and one of the backup entries is less than c times the average distance between adjacent nodes, the message is forwarded directly to that node. Their experiments indicate that these optimizations work in practice. The first optimization reduces the average routing delay penalty by 13%, while the second optimization, with optimal value of c, reduces it by 7-8%. However, there is a weakness in the probabilistic second optimization. Since the backup nodes are not visited as often as the primary nodes, an overhead due to failures might offset the potential improvement. Zhang et al. [15] also state that these optimizations are equally applicable to Tapestry, since it uses same kind of prefix-based routing and locality awareness. Additionally, they state that the first optimization can be used with Chord. Instead of just one successor, Chord often uses list of k next successors. There is certain probability that the queried key actually maps to one these successors. The second optimization can not be adapted to Chord, since it does not take locality into account. We think that the first optimization works well in reality and is simple to implement. Additionally, we agree with Zhang et al. about this optimization having no downsides. The second optimization is not that straightforward, since it increases the already complex implementation possibly too much. Furthermore, it requires a thorough study of constant c before it is known to be optimal in any application. 5 Conclusions This paper introduced four existing peer-to-peer infrastructures; one belonging to the first generation and others to the second generation. Specifically, these were Gnutella,

8 Changing system Stabilization (nodes Searching (number Congestion (popular size joining and disjoining) and kind of requests) items, distribution of keys) Gnutella Poor. The flooding-based Good. The joining is a Poor and restricted. Poor. Congested peers routing mechanism does fairly quick process. The network is flooded are not considered in not scale, since the Also, Gnutella uses with queries, which do any way. A node with network tends to fill heartbeat messages to not reach all of the a popular item might up with messages. determine whether the nodes that might have have to send it neighbors are still matching objects. continuously. alive. Tapestry Good. Consistent hashing Fair. In addition to Excellent. The cost of Good. Tapestry s balances the load in the polling the network to searching is infrastructure supports network. Growing network detect link failures, logarithmic in relation replication indirectly. size does not affect the many messages must be to the network size. Each node publishes the functionality appreciably. sent when node is Additionally, it copy of the object joining or leaving the performs even under itself. Therefore, The network. Backups are frequent failures due number of congested kept for each routing to intelligent algorithm. peers should diminish. table entry to address possibly frequent departures. Pastry Good. Consistent hashing Fair. Like Tapestry, Excellent. The cost of Good. Pastry s design balances the load in the Pastry polls the network searching is supports replicas also. network. Growing network for link failures. Its logarithmic in relation For example PAST [14], size does not affect the repair mechanism is a to the network size. a file sharing utility functionality appreciably. little simpler than that Additionally, it built on Pastry, stores of Tapestry s, but many performs even under file replicas on a set messages are used there frequent failures due of nodes. too. to intelligent algorithm. Chord Good. Consistent hashing Fair/Good. Chord is said Excellent. The cost of Fair. Chord does not balances the load in the to have less maintenance searching is provide replication but network. Growing network overhead than most of logarithmic in relation leaves this to size does not affect the the DHT-based systems. to the network size. application developers. functionality appreciably. At the same time, it is Additionally, it more vulnerable against malicious nodes. performs even under frequent failures due to intelligent algorithm. Table 2: A collection of the qualitative properties of the algorithms covered in this paper in relation to scalability. Tapestry, Pastry and Chord. We compared these protocols in relation to scalability, or in other words, the adaptability of both search and stabilization algorithms as well as to changes in the network size. The results are roughly collected to the table 2. As expected, Gnutella lacks scalability because of its usage of flooding-based forwarding algorithm. Neither does it address congested peers properly. The remaining structured overlay networks perform well regarding scalability, but with the cost of supporting only exact-match queries. These DHTbased substrates address congestion through consistent hashing, which leads to even distribution of the keys among the peers. Also, all of these algorithms do not take locality into consideration, even though locality improves query performance significantly. In chapter 4 we went through some previous researches that try to improve peer-to-peer systems scalability by proposing extensions to the basic behavior. Some of these would better the scalability of the systems. For example, caching the query results in Gnutella nodes seems to be an excellent, downward compatible, upgrade to the algorithm. In the future, we would like to see well scalable applications, which are built on the structured peer-to-peer substrates, but extend these with keyword searching support. However, Gnutella may survive in the future through new versions with improvements that make it more scalable. Gnutella is widely deployed and simple architecture, which will appeal the development community in the future too.

9 References [1] DePaoli, F. and Mariani, L. Dependability in peer-topeer systems. Internet Computing., 8(4):54 61, Jul. Aug [2] Kelaskar, M. and Matossian, V. and Mehra, P. and Paul, D. and Parashar, M. A study of discovery mechanisms for peer-to-peer applications. In Cluster Computing and the Grid 2nd IEEE/ACM International Symposium CCGRID2002., pages , May 21th May 24th [3] Michalis Faloutsos and Petros Faloutsos and Christos Faloutsos. On power-law relationships of the internet topology. In SIGCOMM 99: Proceedings of the conference on Applications, technologies, architectures, and protocols for computer communication, pages ACM Press, [4] Sripanidkulchai, K. and Maggs, B. and Zhang, H. Efficient content location using interest-based locality in peer-to-peer systems. In INFOCOM Twenty- Second Annual Joint Conference of the IEEE Computer and Communications Societies., volume 3, pages IEEE, Mar. 30th Apr. 3rd [5] Mihajlo A. Jovanovic and Fred S. Annexstein and Kenneth A. Berman. Scalability issues in large peer-to-peer networks a case study of gnutella. ECECS Department, University of Cincinnati, Cincinnati, OH , Jan [6] Portmann, M. and Sookavatana, P. and Ardon, S. and Seneviratne, A. The cost of peer discovery and searching in the gnutella peer-to-peer file sharing protocol. In Networks, Proceedings. Ninth IEEE International Conference., pages , Oct. 10th Oct. 12th [7] Markatos, E.P. Tracing a large-scale peer to peer system: an hour in the life of gnutella. In Cluster Computing and the Grid 2nd IEEE/ACM International Symposium CCGRID2002., pages 56 65, May 21th May 24th [8] Patro, S. and Hu, Y.C. Transparent query caching in peer-to-peer overlay networks. In Parallel and Distributed Processing Symposium, Proceedings. International., page 10 pp., Apr. 22th Apr. 26th [11] Ben Y. Zhao and John D. Kubiatowicz and Anthony D. Joseph. Tapestry: An infrastructure for faulttolerant wide-area location and routing. Technical Report UCB/CSD , Computer Science Division (EECS), University of California, Berkeley, California 94720, Apr [12] Zhao, B.Y. and Ling Huang and Stribling, J. and Rhea, S.C. and Joseph, A.D. and Kubiatowicz, J.D. Tapestry: a resilient global-scale overlay for service deployment. Selected Areas in Communications, IEEE Journal., 22(1):41 53, Jan [13] Rowstron, A. and Druschel, P. Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. In IFIP/ACM International Conference on Distributed Systems Platforms (Middleware)., pages , Heidelberg, Germany, Nov [14] Druschel, P. and Rowstron, A. Past: a large-scale, persistent peer-to-peer storage utility. In Hot Topics in Operating Systems, Proceedings of the Eighth Workshop., pages 75 80, May 20th May 22th [15] Rongmei Zhang and Hu, Y.C. and Druschel, P. Optimizing routing in structured peer-to-peer overlay networks using routing table redundancy. In Distributed Computing Systems, FTDCS Proceedings. The Ninth IEEE Workshop on Future Trends of., pages , May 28th May 30th [16] Ion Stoica and Robert Morris and David Karger and M. Frans Kaashoek and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet applications. In Proceedings of the ACM SIGCOMM 01 Conference., pages , San Diego, California, Aug [17] Ion Stoica and Robert Morris and David Liben-Nowell and David R. Karger and M. Frans Kaashoek and Frank Dabek and Hari Balakrishnan. Chord: a scalable peer-to-peer lookup protocol for internet applications. IEEE/ACM Transactions. Networking., 11(1):17 32, Feb [18] Dong Xuan and Chellappan, S. and Krishnamoorthy, M. Rchord: an enhanced chord system resilient to routing attacks. In Computer Networks and Mobile Computing, ICCNMC International Conference., pages , Oct. 20th Oct. 23th [9] Yatin Chawathe and Sylvia Ratnasamy and Lee Breslau and Nick Lanham and Scott Shenker. Making gnutellalike p2p systems scalable. In SIGCOMM 03: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications, pages ACM Press, [10] Anurag Singla and Christopher Rohrs. Ultrapeers: Another step toward gnutella scalability. version 1.0., Nov