Xeja: A Scalable Channel-Based Multi-Source Content Distribution System
Pei Zheng
Department of Computer Science Arcadia University Glenside, PA 19038 Email: [email protected]
Abstract
Aiming at improving file download speed, existing 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 Xeja1, a scalable P2P multi-source content distribution system to solve those problems. Xeja has a flexible channel-based distributed directory service to provide each peer an aggregate of content index 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 existing 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 existing large scale content distribution systems is the directory service, which generally consists of an index server and a tracker server.
The index server (e.g., a web server) hosing all the metadata of shared content. A user will have to contact the index 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 index server sites to look for a specific content.
Another drawback of existing 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 multi- source content distribution system to solve those problems.
Xeja employs a flexible channel-based distributed directory service scheme to provide each client an aggregate of content index 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
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 existing 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 index 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 extensive 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 index 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 exchange. 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 channel- based distributed directory service without using a central tracker server. Within a channel the seeding problem is solved by leveraging cross-horde coordination and sub- tracking load balancing.
3. Xeja Architecture
Peer Join
Peer Channel X
(a) (b)
Channel List
Metadata Pushing
Piece Swarmming Get List
Channel X
Figure 1 CDS in Xeja
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.linux). 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
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 example, 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 sub- seed 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 example 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.
Seed Sub- Seed Horde Member PPS (Proactive Piece Seeding) Piece Exchange Tracking/
Seeding
Figure 2 PPS in Xeja
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 example, a channel
“comp.os.linux.kernel” indicates that this is a channel for users who share the common interest with Linux kernel.
As the ID implies, a channel always resides in a hierarchical namespace. Peers in a lower-level channel (comp.linux.kernel) are also members of its parent channel (comp.linux). 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.
4.2. 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
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.linux.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 sub- seeding 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 sub- seeds available for PPS.
4.3. Proactive Piece Seeding
1 2 3
1 2 3
1 x
(a) r={2,2,2}
1 2 3
1 2 3
x
(b) r={3,3,3}
2 3 1
1 2
Sub-Seed Seed
1 2 3
1 2 3
x
(c) r={4,3,4}
2 3 1
1 3
x x
Figure 3 PPS example
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 check- piece message is exchanged in a certain interval to exchange 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 sub- seed is about to leave ((b) of Figure 3), one of the sub- seeds 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 exchange. A sub-seed maintains the entire horde state by exchanging 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 exchange 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.
4.4. 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
exchange) 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 sub- seeds 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 exchange bit filters of file pieces with each other and exchange pieces accordingly. Note the sub- seeds 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 sub- seed, 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 explore the performance and effectiveness of the channel-based distributed directory service and proactive piece seeding mechanism.
5.1. 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 existing 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, 2004. The SuperTracker can be easily modified to trace other multi- source content distribution systems such as eDonkey/Overnet or Gnutella. We use BitTorrent as an example 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.
0 50 100 150 200 250 300 350
0 20 40 60 80 100 120 140 160
Ranked Horde
Ave. Number of Nodes
Number of Seeds and Peers in a Horde
Seeds Peers
Figure 4 Average number of seeds and peers across all hordes over the tracing period
0 50 100 150 200 250 300 350 0
500 1000 1500 2000 2500 3000
Number of Seeds and Peers
Time (quarter of an h )
Num of Nodes
Seeds Peers
Figure 5 Total number of seeds and peers on a tracker server over the tracing period
2 3 4 5
0.4 0.5 0.6 0.7 0.8 0.9 1
Channel Subscription Succ. Rate
Join TTL
Succ. Rate
Channel A Channel B
Figure 6 Channel subscription successful rate against join TTL
0 2 4 6 8
0 50 100 150 200 250 300 350
Content Availability
Xeja Core Size
Num of Avail. HOrdes
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 expect 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 examine 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 examine the effectiveness of load- balancing 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 fixed 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 flexible channel-based
distributed directory service scheme to provide each client an aggregate of content index 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 existing 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 index server is used to publish a list of available channels in the system. We plan to eliminate the channel index 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 explore system design issues in a real large scale P2P environment.
Reference
[1] The BitTorrent Protocol Specification v1.0,
http://wiki.theory.org/index.php/BitTorrentSpecificatio n, 2004
[2] eDonkey2000/Overnet, http://www.edonkey2000.com/, 2004
[3] B. Cohen, "Incentives Build Robustness in BitTorrent,"
Proc. P2P Economics Workshop, 2003.
[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, 2000.
[5] Y. H. Chu, S. Rao, and H. Zhang, "A Case for End System Multicast," Proc. ACM SIGMETRICS, Santa Clara, CA, 2000.
[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, 2001.
[7] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S.
Shenker, "A scalable content-addressable network,"
Proc. ACM SIGCOMM, 2001.
[8] B.Y.Zhao, J. D. Kubiatowicz, and A. D. Joseph,
"Tapestry: An infrastructure for fault-resilient wide- area location and routing," Technical Report UCB//CSD-01-1141, U.C.Berkeley 2001.
[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, 2001.
[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, 2002.
[11] P. Ganesan, Q. Sun, and H. Garcia-Molina, "Yappers:
A Peer-to-Peer Lookup Service over Arbitrary Topology," Proc. IEEE INFOCOM, 2003.
[12] Y. Chawathe, S. Ratnasamy, and L. Breslau, "Making Gnutella-like P2P Systems Scalable," Proc.
SIGCOMM'03, 2003.
[13] C. Wang, L. Xiao, Y. Liu, and P. Zheng, "Distributed Caching and Adaptive Search in Multilayer P2P Networks," Proc. ICDCS'04, 2004.
[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, 2003.
[15] R. Sherwood, R. Braud, and B. Bhattacharjee, "Slurpie:
A Cooperative Bulk Data Transfer Protocol," Proc.
IEEE INFOCOM, Hong Kong, 2004.
[16] J. Byers, J. Considine, M. Mitzenmacher, and S. Rost,
"Informed Content Delivery Across Adaptive Overlay Networks," Proc. SIGCOMM'02, 2002.
[17] Google Groups/Deja, http://groups.google.com or http://www.deja.com
