1. Introduction. Keywords: content distribution, overlay, peer-to-peer

Transcription

1 Xeja: A Scalable Channel-Based Multi-Source Content Distribution System Pei Zheng Department of Computer Science Arcadia University Glenside, PA zheng@arcadia.edu Abstract Aiming at improving file download speed, eisting large-scale P2P content distribution systems substantially employ a multi-source parallel downloading scheme to allow peers serving each other in a horde. Those systems rely on a single server to provide a directory service of all the hosted content, which may become a bottleneck while the population of peers increases rapidly. Seeking for interested files, users have to browse a number of directory service sites. The lack of coordination between directory services and between content distribution hordes make those systems hard to scale and difficult to search. We propose Xeja 1, a scalable P2P multi-source content distribution system to solve those problems. Xeja has a fleible channel-based distributed directory service to provide each peer an aggregate of content inde automatically collected from peers who share some common interest. In addition, Xeja leverages the coordination between peers in the channel hierarchy in order to improve content availability. Our traces collected from BitTorrent and simulation result show that Xeja can be built on top of eisting multi-source content distribution systems, and the distributed directory service in Xeja effectively improves system scalability while offering a comparatively high availability of shared content. Keywords: content distribution, overlay, peer-to-peer 1. Introduction The Internet in a sense is a large content distribution system. Unlike commercial proprietary content delivery networks such as Inktomi, an open distributed large scale content distribution overlay can be built in the Internet, which enables any user to share and distribute any content among a vast number of peers at any time. The number of client hosts and their underlying overlay topology in such a virtual network may vary considerably from time to time. There has been a great amount of effort on improving the performance of such systems in terms of overall file download speed and bandwidth consumption. Well-know systems such as BitTorrent [1] and edonkey/overnet [2] are able to dramatically increase file download speed by leveraging multi-source parallel download of file pieces among a group (the horde) of peers. The distributed horde 1 Xeja was named by modifying the once very famous Internet newsgroup Deja, which employed a hierarchy structure of groups to categorize user s interest. scheduling algorithm largely determines the overall file download performance of these systems. A major drawback of eisting large scale content distribution systems is the directory service, which generally consists of an inde server and a tracker server. The inde server (e.g., a web server) hosing all the metadata of shared content. A user will have to contact the inde server to search for specific content and retrieve the metadata of the interested file. After that the user launches the client download software to connect to a tracker server in order to get a list of peers who are downloading the same file. In effect, such a directory service does not scale well as it cannot accommodate a large number of requests when the population of the system increases rapidly, as described in [3]. Moreover, since there is no central search service available, a user has to visit numerous inde server sites to look for a specific content. Another drawback of eisting large scale content distribution systems is the seeding problem due to the asynchronous arrival of download request: A seed, a peer with the complete piece set of the file, may leave the horde after serving for some time. When all the seeds are offline, it is very likely that there are some missing pieces among all the active peers in the horde. Accordingly, those active peers will not be able to download the entire file, even if they just miss one or two pieces. Since there is an opportunity that a peer can schedule the upload of pieces to others, some piece distribution algorithms are designed as an effort to evenly distribute all pieces based on the peer s local knowledge of piece distribution. However, such a scheme requires a peer to maintain piece state information of file pieces, and this information maybe largely biased, thereby making the algorithm hard to design and less effective. In this paper, we propose Xeja, a scalable P2P multisource content distribution system to solve those problems. Xeja employs a fleible channel-based distributed directory service scheme to provide each client an aggregate of content inde automatically collected from users who share some common interest. There is no directory server in Xeja. Additionally, Xeja leverages the coordination among peers in the channel hierarchy in order to improve availability of a complete piece set. Rather than statistically optimizing piece distribution algorithms to evenly distribute all pieces of a file among all downloading peers, Xeja s download component is designed to guarantee the availability of a complete piece set. In effect, Proactive Piece Seeding will dynamically

2 distribute all the pieces of a file from a seed to a number of carefully selected sub-seeds, which act as sub-trackers to maintain horde state information and direct peers to other horde members. Our traces collected from BitTorrent and simulation result show that Xeja can be built on top of eisting multi-source content distribution systems, and the distributed directory service in Xeja effectively improves system scalability while offering a comparatively high availability of share content. The contributions of the paper are summarized as follows: We propose a distributed channel-based content distribution directory service and its underlying piece distribution algorithm to improve scalability of the system by eliminating the inde server and tracker server from the system; We design and implement a SuperTracker to monitor and trace horde state dynamics on tracker servers in BitTorrent networks. We provide an etensive analysis on traced multi-source download horde dynamics. To our knowledge, it is the first such effort in P2P and content distribution research community. Our simulation based on the traces collected from BitTorrent and the analysis proves that Xeja will outperform BitTorrent in terms of system scalability and file availability. 2. Related Work The issue of large scale content distribution over the Internet has been actively researched lately due to the dramatic increase of population of broadband users. Traditional FTP-like approaches will fail as the high bandwidth consumption makes it impossible to accommodate hundred of thousands of users. Overlay multicast [4, 5] replaces IP multicast as a major scheme to address the bandwidth issue, largely because of IP multicast s lack of deployment in the current Internet. On the other hand, Peer-to-Peer based content distribution schemes emerged along with popular real working systems. To this end, a significant amount of effort has been made on file search using either structured [6-9] or unstructured [10-13] architecture. A few P2P systems or content distribution networks are proposed to address the issue of scalable and efficient file download with either a stateful overlay [14, 15] or erasure coding [16]. But to our knowledge no open large scale content distribution architecture has been introduced in literature that provides both scalable distributed directory service and multi-source self-organized download service. Sluppie [15] is cooperative multi-source data transfer system that aims to make the horde adaptable to network size and link bandwidth. Its major design goal is improving download performance with the assumption that the seed is always available. In contrast, Xeja s design goal is to provide a distributed directory service to improve file availability and system scalability, which are different aspects of the whole issue. Unlike [16], Xeja takes a stateful approach to form a download horde, and effectively addresses the limitations of stateful systems such as seeding and tracker server problems by Proactive Piece Seeding and sub-tracking. BitTorrent [1, 3] is a file distribution system that relies on an inde web server and a tracker server for content location and downloader hoard state maintenance. The tracker server collects and maintains the state information of all the hordes in order to direct downloader s requests to other downloaders for piece echange. Thus the tracker may not be able to service when the peer population increases rapidly. Furthermore, in BitTorrent, the availability of a complete file is largely determined by the popularity of the file. Xeja is designed to offer a channelbased distributed directory service without using a central tracker server. Within a channel the seeding problem is solved by leveraging cross-horde coordination and subtracking load balancing. 3. Xeja Architecture Channel List Get List Peer (a) Channel X Join Metadata Pushing Piece Swarmming Figure 1 CDS in Xeja Channel X Peer Xeja is channel-based content distribution overlay utilizing self-organized multi-source parallel download and state maintenance. There are two components in the Xeja architecture: Channel Directory Service (CDS), Proactive Piece Seeding (PPS) and Sub-Tracking. CDS is the service to automatically locate content a peer may be interested in the peer s subscribed channels. As shown in Figure 1, a peer chooses to join Xeja by first identifying some channels she is interested with (e.g., comp.os.linu). The list of available channels can be viewed one a web server. The namespace of channels follows a hierarchy rather than a flat list. With the channel IDs the peer will initiate a join operation to find peers in the same channels by broadcasting the request on the overlay. Upon receiving the join request, peers in the underlying channel will reply with a number of peers she knows in the same channel. As a result, the new peer will be able to establish a number connection to some peers in the channel. Essentially each peer in Xeja subscribes to a number of channels, within which she is able to download content metadata and interested files published in that channel with the help of other peers subscribing to the same channel. In a sense, the channel is a closely (b)

3 maintained online community of peers who share the common interest of a specific topic. The mechanism that enables fast and high-availability file download within a channel are PPS and sub-tracking. PPS effectively improves content availability of Xeja. The basic idea is that pieces of a file will be evenly distributed to some carefully selected peers in the channel, namely Xeja core. The sub-seeds could be seeds for other files, or peers that intend to serve others. In effect, the sub-seeds will provide multiple copies of each piece of the file. As a result, even if no seeds are available at some time, a peer can still download the entire file successfully with the help of those sub-seeds. Xeja core ensures the availability of each piece even if some sub-seeds go offline. For eample, if the number of copies of a piece reaches a threshold, another sub-seed (either within the current horde or not) will be found and that piece will be copied over. Disk spaces used by PPS on sub-seeds can be reclaimed after a period of time specified by a user. According to PPS, the locally maintained upload/download rate of each connected horde members is used to determine the outgoing upload rate to them. Unlike BitTorrent, SODON employs cross-horde coordination among horde members and sub-seeds in order to further improve individual download rate. Being a subseed substantially increases the effective upload rate of the peer, making it possible to achieve higher download rate while being served by other peers. Sub-tracking is a mechanism designed to eliminating central tracker server by distributing horde state maintenance task over sub-seeds. A horde member, once connected to a sub-seed, will report state information to the sub-seed. The sub-seed, also a sub-tracker now, will periodically broadcast a list of all its connected horde members to other sub-trackers. An eample of PPS is shown in Figure 2. The seed and three sub-seeds serve five horde members, each connecting to a sub-seed for horde state update. The three sub-seeds and the seed keep an updated list of horde members and at least two complete sets of all pieces. Thus even if the seed leaves the horde later, the sub-seeds are still able to serve interested horde members in a configured period of time. Figure 2 PPS in Xeja Seed Sub- Seed Horde Member PPS (Proactive Piece Seeding) Piece Echange Tracking/ Seeding 4. Design Issues Four issues are identified as follows: o How to organize and maintain CDS distributely? o Which peers will be selected as the sub-seeds? o How to distribute a file over all those sub-seeds? o How to distribute peer tracking request and update from horde members to sub-trackers? 4.1. CDS Xeja adopts a channel hierarchy similar to the well known newsgroup site Google groups [17], formerly known as Deja. A channel is uniquely identified by a string in the format of a.b.c.d.e.f, whereby each letter representing a special keyword. For eample, a channel comp.os.linu.kernel indicates that this is a channel for users who share the common interest with Linu kernel. As the ID implies, a channel always resides in a hierarchical namespace. Peers in a lower-level channel (comp.linu.kernel) are also members of its parent channel (comp.linu). A peer only maintains a persistent bilateral relationship with some number of peers in a channel, resulting in a loosely connected channel member overlay. No global channel membership information needs to be maintained locally at each peer. When the number of active peers maintains at a peer falls below a threshold (we use 6), or there is a new peer to subscribe to the channel, it will initiate a join operation, which takes a simple broadcasting approach if the peer does not know anyone else in the channel; otherwise, the peer will just ask those peers. Note that during bootstrapping, a new peer is always connected to some other peers who are members of high-level channels. When a peer chooses to unsubscribe from the channel, only its neighbors in the channel will be notified and updated accordingly. It is possible that two clusters of peers are not directly connected even if there are in the same channel. However, the join operation serves as a remedy for this problem: it is very likely that when a new peer broadcasts a join channel request, she will be able to receive lists of peers in the same channel from the other cluster. Therefore the two clusters of the same channel are connected through the joining peer. All the peers in a channel are ready to receive publishing announcement in the form of a metadata file. To publish a new content in a channel, a peer (the initial seed) will create a small metadata file and transmit it to other peers in the channel. The metadata file consists of two parts: the fist part is the necessary descriptive information of the shared content; the second is a summary of all the pieces for the file, including the number of pieces and each piece s hash code. Within the channel, the metadata file will be distributed to all the peers the initial seed can reach Sub-Seed Selection A peer in Xeja has two working modes for each channel: the content mode and metadata mode. In the content mode, a peer is willing to receive whatever content published in the channel without prompting the user for approval; in the metadata mode, a peer will only receive metadata files published in the channel. After that the user has an opportunity to choose what to download after reviewing the metadata file. In reality, the content mode is

4 designed for Xeja users who are optimistic about the content published in her subscribed channels. Note that if the channel is carefully designed to facilitate the need of useful content distribution over a group of closely connected users such as comp.os.linu.iptables, many peers are likely to choose the content mode for this channel. To publish a new content in a specific channel, after publishing the metadata file, the initial seed will try to find a number sub-seeds to distribute the content. Sub-seeds are chosen among peers who are operating in content mode in the channel. The initial seed will send a sub-seeding request to each content-mode peer in the channel for a report of local machine information, including CPU, memory size, network connection type (dial-up, cable modem, DSL, or LAN), data upload rate, a vector of time of last m online durations, recent data upload rate, and previous seeding and sub-seeding history. The subseeding request is further forwarded at each peer in order to reach many content-mode peers. To avoid too much traffic overhead, a TTL will be set for the sub-seeding request to limit the scope of the sub-seeds searching. Then those candidates with a higher serving capability will be selected as sub-seeds. If enough number of sub-seeds is available for sub-seeding by the initial seed, they can proceed to conduct PPS. Otherwise, the initial seed simply gives up PPS at this time and begins to push pieces to those content-mode peers without conducting PPS. However, the initial seed or other seeds may try to conduct such a sub-seeding request operation on a timely basis for a number of times until there is enough number of subseeds available for PPS Proactive Piece Seeding 1 (a) r={2,2,2} Sub-Seed Seed (c) r={4,3,4} 1 3 (b) r={3,3,3} Figure 3 PPS eample In Xeja, the entire file is evenly divided into a number of pieces. Let r be the redundancy vector, which denotes the number of available copies of each piece of the file among the seed and sub-seeds. Essentially PPS can be regarded as a piece distribution tree, as shown in Figure 3. Depending on r and the number of complete copies of the file the initial seed needs to maintain, the initial seed will find some number of sub-seeds to form a Xeja core, and copy r number of pieces to each of them. The Xeja core keeps an updated PPS table as who has which pieces. Some sub-seeds may become a seed once it has a complete piece set. Between the seeds and each sub-seed, a checkpiece message is echanged in a certain interval to echange information of available pieces. If a sub-seed leaves the core and the initial seed is still working, as shown in (a) of Figure 3, the initial seed will have to find another sub-seed, and inform other sub-seeds of this change. If the initial seed has left the core and then a subseed is about to leave ((b) of Figure 3), one of the subseeds will conduct a sub-seed searching operation among content-mode peers for a new sub-seed. We choose to maintain all the updated piece state information at each sub-seed, i.e., a sub-seed will have a PPS table of entries as bit filter and its sub-seed. The reason of this choice is based on two observations. One is that sub-seeds are quite stable peers that do not frequently go online/offline (they are in content-mode anyway), so maintenance cost of a complete PPS table is not very high. The other observation is that generally the size of a PPS table is not large as the number of pieces is at most several thousands in reality with a piece size of less than 1 Mbytes. In order to adapt to increasing popularity of the file, the seed or some sub-seeds may decide to increase the duplication number. To achieve this, a sub-seed may simply act as if it is a seed and start to build a PPS distribution tree. Such a process is completely transparent to other sub-seeds, as shown in (c) of Figure 3. The only update information other sub-seeds and the seed need to know is that there are more pieces being serviced by the underlying sub-seed. A sub-seed in a Xeja core will also be responsible for maintaining download horde state information, which is a list of peers who are active downloading the content in addition to sub-seeds and seeds. In addition, a sub-seed will act as a sub-tracker to tell interested peers a list of other horde members for piece echange. A sub-seed maintains the entire horde state by echanging horde member update information between each other in a gossip manner on a timely basis. It is clear that a state update will be gradually passed to all sub-seeds after a number of gossip rounds, resulting in some inconsistency of horde state on different sub-seeds during this process. However, as long as a horde member is able to receive a list of some active members, it can begin to echange piece immediately while frequently checking for new active members at its connected sub-seed. In other words, the system can tolerate such horde state inconsistency among sub-seeds for a while provided that there are valid active horde members to begin with. Nonetheless, even if the horde state reported from a sub-seed is completely outdated, the horde member may just wait for a short warm-up time and then try again Sub-Tracking and File Download In Xeja, the file download operation is actually carried out in two stages as shown in Figure 2: swarming (piece

5 echange) among horde members, and if needed downloading pieces unavailable among horde members form sub-seeds. By asking these sub-seeds, the horde members will be able to know other horde members who are now in the horde downloading the file. Those subseeds being asked then update their horde member list to reflect the update of horde state and gossip the change between each other. At the same time, the horde member can proceed to echange bit filters of file pieces with each other and echange pieces accordingly. Note the subseeds may also join the swarming in the first stage. If the first stage turns out to be successful, there will not be the second stage. Depending on the number of horde members a peer wants to know while asking its sub-seed (sub-tracker), a peer may only see a subset of all the horde members in the underlying horde. When the horde member cannot find any new pieces available for download, it can ask the subseed, which serves like an agent for the horde member to find out where to get the desired pieces from the Xeja core. Hence, if a peer sends a request to one of the sub-seeds asking for some pieces, the sub-seed will consult the PPS table for a number of sub-seeds that can provide all the required pieces. The PPS should ensure that load of piece download will be evenly distributed among sub-seeds. Then the download can proceed to download those missing pieces from responding sub-seeds. Since multi-source download system relies on peers serving each, an incentive mechanism is needed to reward serving peers and punish pure downloaders. The general rule is that horde members who show a higher upload rate to others should benefit from serving others. Designed for system scalability and content availability rather than overall performance, Xeja is able to adopt any piece scheduling algorithms such as the choking algorithm used in BitTorrent for overall performance. In addition, a special incentive mechanism is devised to encourage peers to be sub-seeds. Specifically, the actual data upload rate of a sub-seed, who serves Horde A and is a member of Horde B, will be computed against a special sub-seed factor (we use 1.2) as the effective data upload rate by a member in Horde B. Thus the sub-seed will enjoy higher data download rate compared with other non sub-seed members. 5. Trace Analysis and Simulation In this section, we first show an analysis on the traces we collected from BitTorrent. Based on that we conduct the simulation of Xeja to eplore the performance and effectiveness of the channel-based distributed directory service and proactive piece seeding mechanism Trace Analysis The network dynamics and overall service characteristics of a large scale multi-source content distribution overlay are very sophisticated and difficult to model and simulate. In order to conduct meaningful simulation of Xeja, we choose to collect trace from eisting popular systems and use it for our simulation after some processing. We design and implement a BitTorrent SuperTracker program to act as a dummy peer in the network in order to trace horde dynamics and tracker server statistics. The traces are collected for 88 hours consecutively in a 15-minute interval from a tracker server site from February 15 to February 18, The SuperTracker can be easily modified to trace other multisource content distribution systems such as edonkey/overnet or Gnutella. We use BitTorrent as an eample to show common characteristics of overlay network dynamics and peer behavior. Given a tracker server hosting many hordes, the number of peers in each horde varies in a very wide range. Our traces on a tracker server show 93% of hordes have an average size (the number of members) of less than 20 members over the tracing period, and 96% of hordes have an average number of seeds less than 3, as shown in Figure 4. The traces further show that, among all those hordes, 296 of them (85%) fail to provide a single seed at least once during our tracing period. The result implies even if with rare-first piece distribution algorithms, a horde still has a high probability of suffering the seeding problem when it becomes unpopular at some point, thereby limiting the availability of those files. However, from the traces we notice that there is always a large number of stable peers constantly acting as seeds to serve others. As shown in Figure 5, although the number of peers across many hordes varies dramatically during the tracing period, the number of seeds serving those hordes seems quite stable (The glitch at time unit 230 was resulted from network congestion that makes the tracker server unable to collect state information from all peers). In fact, those seeds are believed to be the ones who have a strong intention to serve others in a multi-source content distribution overlay such as Xeja, in which they are likely to be those peers working in content-mode in a channel. Consequently, we argue that, based on the stable number of seeds in the trace, PPS among sub-seeds in Xeja is feasible, as there seems to have a large number of content-mode peers in a channel. Ave. Number of Nodes Number of Seeds and Peers in a Horde Seeds Peers Ranked Horde Figure 4 Average number of seeds and peers across all hordes over the tracing period

6 Num of Nodes Succ. Rate Number of Seeds and Peers 3000 Seeds Peers Time (quarter of an h ) Figure 5 Total number of seeds and peers on a tracker server over the tracing period 1 Channel A Channel B Channel Subscription Succ. Rate Join TTL Figure 6 Channel subscription successful rate against join TTL Num of Avail. HOrdes 350 Content Availability Xeja Core Size Figure 7 Content availability against Xeja core size 5.2. Trace-Driven Simulation The simulation of Xeja is based on the collected traces. For simplicity a horde is mapped into a channel in Xeja, although in reality a channel may host multiple hordes. The number of seeds and peers of each horde is obtained from our traces. Each shared file has 1024 pieces. Note that file size and piece size is not important for the investigation of content availability. The sub-seeds are selected by randomly choosing a specific number of seeds in other hordes, since we epect those seeds are likely to work in content mode in the channel. The redundancy of each piece is set to 2 among sub-seeds. Pieces are evenly distributed among those selected sub-seeds. Note that each Xeja network serving many channels may need specific configuration of these system parameters. We choose these settings in order to quickly have a proof-of-concept system, leaving the issue of optimization to future work. We first eamine channel availability and overhead of subscription to a channel. In our simulation, a peer may choose to join one to three channels. Within a channel, a peer is set to maintain a list of 10 randomly selected neighbors. Thus all the peers essentially organize into an overlay network, which is not necessarily a connected graph. Figure 6 shows the average channel subscription successful rate of 100 new peers against the TTL of the join message. Each new peer joins a specific channel with randomly selected overlay neighbors, whereas Channel B is a parent channel of Channel A. It can be seen that with a join TTL of 5, almost all peers will be able to connect to the channel, and the overhead of these join messages is moderate. The content availability in Xeja is a combination of two issues: during the creation phase, the possibility of having enough sub-seeds to perform PPS; and during the seeding phase, the possibility of having enough qualified seeds and sub-seeds for PPS (in case some sub-seed leaves the horde) and seeding. In the simulation, we use 3-day as the interval of disk space reclamation on each sub-seed. Figure 7 shows the availability of Xeja compared with BitTorrrent, whose Xeja core size is 0. It is clear that when the core size is small, most of hordes will be able to maintain at least one complete piece set. Therefore, compared with BitTorrent, Xeja with PPS will show a higher availability for complete file downloading. The overhead traffic of PPS, which includes the piece distribution cost and the maintenance cost due to leaving sub-seeds, is minimal compared with the traffic on traditional tracker server. Result of overhead traffic is skipped due to space limit. We also want to eamine the effectiveness of loadbalancing of sub-tracking. The load on each sub-tracker in a Xeja core can be measured by the number of tracking requests and updates it has to handle in a fied interval. Our results show that load on sub-trackers is reduced as much as 72% and 42% for cores size of 4 and 2 respectively, even though sub-trackers are required to maintain a global state of the entire Xeja core. 6. Conclusion and Future Work We propose Xeja, a scalable P2P multi-source content distribution system that addresses both the issue of distributed directory service and the issue of content availability. Xeja employs a fleible channel-based

7 distributed directory service scheme to provide each client an aggregate of content inde automatically collected from users who share some common interest. In addition, Xeja leverages the coordination among peers in the channel hierarchy by utilizing the Proactive Piece Seeding scheme in order to improve availability of a complete set of file pieces. Our traces collected from BitTorrent and simulation result show that Xeja can be built on top of eisting multi-source content distribution systems, and the distributed directory service in Xeja effectively improves system scalability while offering a comparatively high availability of shared content. Currently in Xeja a channel inde server is used to publish a list of available channels in the system. We plan to eliminate the channel inde server, and make it possible to create new channels and publish them in a fully distributed manner. We are in the process of implementing a prototype of Xeja to further eplore system design issues in a real large scale P2P environment. [14] M. Castro, P. Druschel, A. Kermarrec, A. Nandi, A. Rowstron, and A. Singh, "Splitstream: High-bandwidth Content Distribution in Cooperative Environments," Proc. IPTPS'03, [15] R. Sherwood, R. Braud, and B. Bhattacharjee, "Slurpie: A Cooperative Bulk Data Transfer Protocol," Proc. IEEE INFOCOM, Hong Kong, [16] J. Byers, J. Considine, M. Mitzenmacher, and S. Rost, "Informed Content Delivery Across Adaptive Overlay Networks," Proc. SIGCOMM'02, [17] Google Groups/Deja, or Reference [1] The BitTorrent Protocol Specification v1.0, n, 2004 [2] edonkey2000/overnet, [3] B. Cohen, "Incentives Build Robustness in BitTorrent," Proc. P2P Economics Workshop, [4] J. Jannotti, D. Gifford, K. Johnson, M. Kaashoek, and J. O'Toole, "Overcast: Reliable Multicasing with an Overlay Network," Proc. OSDI 2000, San Diego, CA, [5] Y. H. Chu, S. Rao, and H. Zhang, "A Case for End System Multicast," Proc. ACM SIGMETRICS, Santa Clara, CA, [6] A. Rowstron and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems," Proc. International Confer-ence on Distributed Systems Platforms, [7] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker, "A scalable content-addressable network," Proc. ACM SIGCOMM, [8] B.Y.Zhao, J. D. Kubiatowicz, and A. D. Joseph, "Tapestry: An infrastructure for fault-resilient widearea location and routing," Technical Report UCB//CSD , U.C.Berkeley [9] R. M. Stoica, D. Karger, M. F. Kaashoek, and H. Balakrishnan, "Chord: A scalable peer-to-peer lookup service for Internet applications," Proc. ACM SIGCOMM, [10] Q. Lv, P. Cao, E. Cohen, K. Li, and S. Shenker, "Search and replication in unstructured peer-to-peer networks," Proc. the 16th ACM Interna-tional Conference on Supercomputing, [11] P. Ganesan, Q. Sun, and H. Garcia-Molina, "Yappers: A Peer-to-Peer Lookup Service over Arbitrary Topology," Proc. IEEE INFOCOM, [12] Y. Chawathe, S. Ratnasamy, and L. Breslau, "Making Gnutella-like P2P Systems Scalable," Proc. SIGCOMM'03, [13] C. Wang, L. Xiao, Y. Liu, and P. Zheng, "Distributed Caching and Adaptive Search in Multilayer P2P Networks," Proc. ICDCS'04, 2004.