JXTA Performance Study - CiteSeerX

JXTA Performance Study Emir Halepovic and Ralph Deters Department of Computer Science University of Saskatchewan, Saskatoon, SK Canada E-mail: {emir.h, deters}@cs.usask.ca defining the JXTA performance model. Several issues are discussed that make the benchmarking of JXTA components a non-trivial task, such as effects of unreliable message-passing, overhead of XML-based protocol definition, source-based routing and network configurations. The benchmarking results of the peer startup time indicate strong dependence on the hardware and software environment, especially the versions of JXTA and the Java Virtual Machine (JVM). The RTT results show that improvements in a subset of components do not necessarily indicate overall benefit and that the peer network configuration plays an important role. The analysis of the results shows that the newer releases of both JXTA and JVM still contain problematic components, which cause either poor or inconsistent performance. The availability of this kind of information may be crucial in a process of system design or in deciding how and when to switch software versions for deployed applications. The rest of the paper is organized as follows. Section II gives an overview of JXTA and Section III describes the benchmarks and design issues. In Section IV, the performance results are presented and discussed. Related work follows in Section V and the paper concludes in Section VI.

Abstract—Project JXTA is the first peer-to-peer application development infrastructure that includes standard protocols and multi-language implementations. Performance and scalability of JXTA are not well understood, despite its widespread usage in research and increasing popularity in the industry. This paper reports on a performance evaluation of the JXTA protocol implementations in Java. The peer startup and pipe performance are evaluated for the JXTA protocol versions 1.0 and 2.0. The results show that the performance of the latter JXTA version has improved for secure message transfer and multicast propagation, but degraded for several other operations. Index Terms—peer-to-peer, performance, platform.

I. INTRODUCTION Project JXTA is an open-source effort to formulate and implement a set of standard peer-to-peer (p2p) protocols. JXTA consists of six protocols that support core p2p operations, such as peer discovery, organization, identification and messaging. JXTA is independent of the programming language, operating system, network topology and underlying communication protocol. The JXTA reference implementation, which was used in the study, is written for the Java 2 Standard Edition. The JXTA protocol implementations have undergone a series of changes aimed at improving their performance, scalability, and reliability. However, JXTA developers still lack benchmarks against which JXTA components can be evaluated to ascertain objective results. The need for a set of benchmarks is amplified by the growing popularity of JXTA in research and industry circles. As JXTA implementations gradually mature, benchmarking results become essential in evaluating the progress and applicability of JXTA to different applications and systems. The existing research applications of JXTA range from RDF-based resource discovery and retrieval [1], to p2p discussion forums [2]. Commercial JXTA products are becoming available as well [3]. However, the performance and scalability of JXTA are still not well understood, despite its popularity. This paper reports on the development of benchmarks for measuring the peer start-up and the JXTA message round-trip time (RTT), as a part of the larger ongoing project aimed at

II. JXTA OVERVIEW JXTA uses open standards like XML as its interoperability foundation. The JXTA reference implementation is available in Java and C, but other language implementations (e.g. Python, Perl) are provided via community projects [4]. In general, p2p applications must handle intermittent connectivity, dynamic IP addresses and an unstable network topology. Therefore, the developers face a challenge of designing applications that are independent of DNS and IP addressing and identification. This is why JXTA introduces a virtual network layer on top of the existing transport protocols. JXTA facilitates interaction in this dynamic environment using its own addressing and routing [5]. This virtual network is able to cross barriers like firewalls and Network Address Translation (NAT), and establish peer communities spanning any part of the physical network. The main concepts in JXTA are described in the following sections, with reference to the example in Fig. 1, where a network of five peers is shown. The following scenario is assumed: peer A provides a weather forecast service, and peer

This work was supported in part by the Natural Sciences and Engineering Research Council of Canada (NSERC).

1

definition, but bi-directional and reliable services are provided on top of them. Two operation modes of pipes are defined: unicast and propagate. Unicast pipes serve for one-to-one communication, whereas propagate pipes connect one sender peer to many receiving peers. The secure version of unicast pipes uses the TLS model for secure message exchange [5]. JXTA messages are XML-documents composed of well defined and ordered message elements [7]. The elements are name-value pairs, and they can carry any type of payload. JXTA uses source-based routing and each message carries its routing information, as a sequence of peers to traverse. The peers along the path may update this information. The routing elements tend to get large, primarily due to the 256-bit peer ID [7], composed of the own and the group ID. This implies that even an “empty” message, with no application-specific payload, can easily reach 1 KB in size, possibly affecting the performance of message exchange.

Fig. 1. A simple JXTA network.

B needs to discover it and request the current forecast report. A. Peers and Peer Groups The JXTA virtual network consists of several kinds of peers [6]. Most of the peers are simple or edge peers, usually desktop computers connected by a LAN or modem to the Internet, such as peers A, C and D. Small devices, such as peer B, are minimal peers, since their resource constraints would most likely disallow full functionality. They use help from the proxy peers (e.g. peer B), for caching, search and discovery. Rendezvous peers are usually more powerful peers, with wellknown DNS name or stable IP address, and they act as caches of information about the connected peers. Relay peers have a special role to learn and provide routing information and pass messages between peers separated by firewalls and NAT. In Fig. 1, peer R acts as both a relay and a rendezvous. Peers organize into peer groups and all communication is constrained to the group members. Peer groups are not limited to the physical network boundaries and the peer membership is not limited to a single group. In the network from Fig. 1, peer D does not receive messages from group G, because it is not a member, although it may use the same rendezvous or relay.

III. BENCHMARKS Several issues make the design of JXTA benchmarks a nontrivial task. The JXTA platform is initialized in such a way that only one peer instance is allowed per JVM. In addition, the only way to shutdown JXTA is by terminating the JVM. This complicates the automated testing of multi-peer environments. A. Startup benchmark The startup test measures the time it takes to initialize the JXTA platform on a single peer. This measurement reflects the minimum time a user waits or an application blocks for the initial response from the JXTA platform. Taking into account all the mentioned constraints, the best option for this test is to measure the startup time inside a Java class, and restart the JVM for every sample, ensuring that only the JXTA platform startup time and not the JVM time is measured. The startup time depends largely on the chosen platform configuration. Among the many factors that affect the peer startup time, size and location of the advertisement cache seems to be the most relevant one. The number and type of advertisements determine the cache size, whose location may be a local disk or a network drive. The peer’s rendezvous and relay settings have additional effects on the startup time by possibly involving remote connections. These connections should be disabled during tests. However, the latency of a connection to the rendezvous peer and the cache effect is investigated as a separate issue in the future works.

B. Pipes and Messages JXTA pipes are a core abstraction used for inter-peer communication, which is based on JXTA messages. The peers pass messages through pipes that act as virtual channels consisting of input and output ends. Peers bind to one end of the pipe and when both ends are bound, messages can be passed. Pipes are not bound to the physical location, IP address or a port. Instead, pipes have a unique ID, so each peer can carry its pipe with itself even when its physical network location changes. At runtime, a pipe end is resolved to an endpoint address to which it is currently bound. In Fig. 1, peer A must open a pipe input end to receive a forecast service requests and publish the pipe’s advertisement. This advertisement can be published either separately or be embedded with a forecast service advertisement. At runtime, peer B obtains the pipe advertisements, and queries the network for the peer who has opened the pipe input end. Once peer A has responded, peer B can open the pipe output end and send the request. Pipes are asynchronous, unidirectional and unreliable by

B. Round-trip time benchmark The basic performance metric for a communication protocol or system is the message round-trip time (RTT). RTT is measured as the time it takes to send a message and receive the acknowledgement (ACK). There are several problems with measuring RTT for JXTA messages, which require certain decisions and assumptions be made. The first decision is whether to use ACK or echo messages. Depending on the test payload size, the message and 2

Average startup time (ms)

10000 8000

in three basic ways, unicast, secure unicast and propagate. In addition, the path between peers may traverse one or more message relays. Although the list of factors is not exhausted, these four are discussed here.

JVM 1.3.1 JVM 1.4.1

6000 4000

IV. RESULTS AND ANALYSIS

2000

This section presents the results obtained by running the described benchmarks on JXTA peers. The peers run on Windows 2000 PCs with Athlon 800 MHz CPUs and 512 MB of RAM, all connected to a 100-Mbit campus LAN.

0 070802

092402

030301

JXTA release

Fig. 2. Peer startup time for three JXTA releases and two JVM versions.

A. Peer Startup Results The average startup times are calculated for peers running three JXTA releases on two versions of JVM. The tested JXTA releases that implement protocol version 1.0 are 070802 (July 2002) and 092402 (September 2002). The protocol version 2.0 implementation is 030301 (March 2003). These are all official stable releases. The peers start with no external advertisements in their local cache, only several of their own. The cache is located on the network drive. The startup results are based on 1,000 samples. The results are shown in Fig. 2. The startup times consistently increase with newer JXTA releases. Under JVM 1.4.1, the performance degradation is minimal, below 15% over two releases. However, the latest release under JVM 1.3.1 starts up to three times slower than earlier releases. The actual delay experienced by the user may be even longer, if the application uses a complex GUI, for example. This may cause serious concern for users that would like to migrate to the latest JXTA 2.0 release but must stay with the older JVM. The two earlier releases started up to 35% faster on JVM 1.3.1. This changed with the latest release, which starts faster on JVM 1.4.1, although it has the JVM 1.3.1 as the minimum requirement. The peer startup time introduces the first trade-off in deciding if and when to switch JXTA or JVM versions. The results suggest that JXTA 2.0 release is optimized for JVM 1.4.1, in respect to operations involved in the peer startup process.

ACK sizes could be significantly different, causing the difference in two trip times. Therefore, half the RTT should not be considered as one-way latency of message transfer. In fact, one-way throughput would be the next appropriate metric to evaluate, which is left for the future work. It is possible to measure the RTT using echo message as well. Both payloads would then be the same size, allowing for a more precise estimation of the one-way latency. However, this approach also has drawbacks. Since JXTA message cannot be reused and simply echoed, they have to be re-created resulting in a noticeable overhead. In addition to this, the source-based routing adds the routing information to the message in the form of peer IDs, which may be of different size for the original and the echoed message. In case of large message sizes, a significantly higher transfer delay is caused, in particular over secure pipes with messages sizes over 1 MB. The ACK approach is used in this study, because it is simpler and faster, as it consistently minimizes the processing at the receiver, and represents a more realistic messaging scenario. Since JXTA pipes are asynchronous and unreliable, polling is used to obtain the ACK as soon as it arrives. JXTA messages may be dropped; therefore, a proper polling timeout must be used. Sender should never wait indefinitely for an ACK; rather it should assume the message is dropped if the timeout occurs. The RTT measurements are taken at the application layer. All overhead costs from converting an XML message to and from a Java object are included in the measurements. These costs are consistent over all send and receive operations. Therefore, this benchmark essentially measures the user’s perception of the message RTT. RTT results for different pipes and peer configurations indicate trade-offs between performance, security and reliability. Secure pipes are expected to introduce a delay penalty due to encryption. Propagate pipes can exploit the availability of IP multicast to improve performance by avoiding the overheads of TCP and HTTP. The application-layer message RTT is affected by a number of important factors in JXTA. JXTA protocols are XMLbased, which involves an overhead in the message composition and processing. In addition, JXTA pipes present a high level of abstraction over underlying TCP and HTTP transports resulting in a certain overhead. Message passing can be done

B. Message RTT Results The measurements of the message RTT were obtained in a setup of two edge peers and when required, one or two relays, all on the same LAN. The RTT represents the time elapsed between the send request and the receipt of the acknowledgment at the sender. The messages are sent sequentially, and each message includes the sender’s pipe advertisement and the message sequence number for the total of 316 bytes. It is common that a JXTA peer sends its own pipe advertisement inside the message, so that a receiver may respond. Processing is minimized at the receiver by reusing the open response pipe. The tests are performed in various configurations to show the effects of pipe type, message size and composition, transport protocols and relays. All results are based on 10,000 acknowledged messages with 1,000-message 3

400

10,000

Average RTT (ms)

Average RTT (ms)

100,000

1,000 100 Unicast Secure Propagate

10 1 1 KB

10 KB

100 KB

1 MB

300

Unicast Secure Propagate

200 100 0

10 MB

1x20KB

Message size

Fig. 3. RTT for different types of pipes and message sizes (JXTA 1.0).

20x1KB

Fig. 5. RTT for various message compositions (JXTA 1.0). 400

100,000 10,000

Average RTT (ms)

Average RTT (ms)

5x4KB 10x2KB Message composition

1,000 100 Unicast Secure Propagate

10 1 1 KB

10 KB

100 KB

1 MB

300

Unicast Secure Propagate

200 100 0

10 MB

1x20KB

Message size

5x4KB 10x2KB Message composition

20x1KB

Fig. 4. RTT for different types of pipes and message sizes (JXTA 2.0).

Fig. 6. RTT for various message compositions (JXTA 2.0).

warm-up period. The JXTA releases 092402 (JXTA 1.0) and 030301 (JXTA 2.0) are evaluated and compared, running on JVM 1.4.1. The RTT measurements were collected for three ways of message passing in JXTA: point-to-point (unicast), secure unicast and propagate (one-to-many). 1) RTT and Message Size: The objective of this test is to understand how different types of pipes behave over the range of message sizes. Each message contains a single payload element of size ranging from 1 KB to 10 MB. The messages are exchanged between two peers using a direct TCP connection. Fig. 3 shows the average RTT of three types of JXTA 1.0 pipes for each of the message sizes (both axes are log scale). Each pipe exhibits slow, close to linear increase in RTT from 1 KB to 100 KB, unicast pipe even to 1 MB. Between 100 KB and 10 MB, the message RTT over the secure and propagate pipes increases at a different and much higher rate, but it seems to also keep the linear trend. The increasing rate for unicast pipe from 1 MB to 10 MB closely follows the rate of other pipes, but it is hard to conclude what would be its possible ongoing trend. It is certainly desirable that message RTT on any pipe increases at most linearly over message sizes. The graph of the maximum RTT (not shown) looks very similar to the graph of the average RTT. By relative comparison, the secure and propagate pipes differ in the order of magnitude consistently. Unicast pipe performs closer to the secure for smaller messages, but converges with the propagate pipe for larger sizes. This indicates better scaling properties of the unicast pipe over TCP

up to the 10 MB message size. The same benchmarking is performed for JXTA 2.0 release and the results are shown in Fig. 4. The general trends are the same as observed for JXTA 1.0. However, some differences do exist. Unicast pipes perform much slower on JXTA 2.0 for message sizes from 1 MB to 10 MB, up to the factor of two. Secure pipes perform much better on JXTA 2.0 for smaller message sizes (1 KB and 10 KB). Propagate pipes perform significantly slower on JXTA 2.0 over all message sizes, up to the factor of three. In fact, the only improvement of JXTA 2.0 in this benchmark is for small message transfers over secure pipes. 2) RTT and Message Composition: The following test looks at the overhead of processing the messages composed of different number and size of the XML elements. Four variations of a 20KB message were used: 1x20KB (1 element of size 20KB), 5x4KB, 10x2KB and 20x1KB. Fig. 5 shows that the performance of JXTA 1.0 secure pipes is very much affected by message composition. On the other hand, there is less effect on unicast and propagate pipes, but it does exist. Increasing the number of elements from 1 to 20, while reducing their size, more than doubles the average RTT on a secure pipe. For unicast pipe, the increase in RTT over four combinations is 24%, and for propagate pipe about 43%. For JXTA 2.0, a very different behavior is observed. Fig. 6 shows that message composition has virtually no effect on performance of unicast and propagate pipes. This is a good property, showing an improvement in JXTA 2.0. The message composition effect on secure pipes is opposite of that observed 4

300 250

350

Unicast Secure Propagate

Average RTT (ms)

Average RTT (ms)

350

200 150 100 50 0

300 250

Unicast Secure Propagate

200 150 100 50 -

Direct TCP/UDP

1 Relay 1 Relay - HTTP TCP/HTTP Peer and relay configuration

2 Relays HTTP

Direct TCP/UDP

1 Relay 1 Relay - HTTP TCP/HTTP Peer and relay configuration

2 Relays HTTP

Fig. 7. RTT for various transports and relay configurations (JXTA 1.0).

Fig. 8. RTT for various transports and relay configurations (JXTA 2.0).

for JXTA 1.0. The newer release handles more small elements better than fewer large ones. Another interesting result is that JXTA 2.0 secure pipes can outperform unicast pipes for smaller message sizes with complex structure. This observation is consistent with the previous RTT test over different message sizes. Overall, the effect of message composition is not very surprising, considering that messages are XML documents and the complexity of document structure affects the processing time. This implies that parsing and encryption sub-systems significantly affect the overall performance of the JXTA system. 3) Effects of Relays and Transports on RTT: JXTA peers can be configured to use TCP, HTTP and UDP in various combinations. TCP is used whenever a direct connection between peers can be established. HTTP is generally used when a firewall or NAT is on the path or a peer specifically wants to use an HTTP relay. UDP is exploited in the form of IP multicast for efficient propagation of messages on a subnet. The measurements of the RTT in different peer configurations and on different transports for JXTA 1.0 are shown in Fig. 7. The messages in this test contain one payload element 1 KB in size. In the direct TCP/UDP configuration, two peers connect directly without any rendezvous or relay. Propagate pipes show much better performance because the peers use available IP multicast. In the second configuration, two peers use a relay on the same LAN, all configured to use both TCP and HTTP, with multicast disabled. The RTT for all pipes increased, as expected, due to the overhead of the relay. While the increase in latency over the unicast and secure pipes is moderate, it almost quadrupled for propagate pipes. This large increase for propagate pipe is caused by removing multicast. The third configuration reveals results that are even more interesting. Here the peers use only HTTP to communicate with the relay. Unicast pipes perform much better in this than in any other configuration, which is quite unexpected, considering overhead of HTTP and a relay. Propagate pipe also shows minimal improvement when TCP is disabled. Secure pipe is slower as expected, again by a moderate amount.

Finally, the two-relay configuration is set up so that relays have both TCP and HTTP enabled, and edge peers use only HTTP to connect to one relay each. The relays pass messages between each other on behalf of their attached edge peers. Secure pipe gets uniformly slower through the configurations, as expected. Compared to the configuration with HTTP and one relay, unicast and propagate pipes also show higher latency, as expected. However, when compared over all four configurations, unicast pipe performs similarly throughout except in a single relay setup with only HTTP transport. Secure and propagate pipes, on the other hand, suffer most from the additional relay, passing messages about twice as slow as with a single relay. Overall, a single HTTP relay costs the propagate pipe over 3 times, and two relays 7 times the cost of IP multicast. In the same configurations, JXTA 2.0 release is evaluated and the results are shown in Fig. 8. The improvement in performance of secure pipes is now seen across different network configurations in respect to the JXTA release. It is surprising to see that secure pipe again outperforms the unicast or propagate pipe in most of the configurations. Again, the propagate pipe suffers most from the relays, when IP multicast is not available. When using multicast, propagate pipes show improved performance over JXTA 1.0 implementation. All pipes perform better when using a single relay with HTTP only, rather than with both TCP and HTTP. One would expect that TCP connections to the relay would have better performance, but the measurements show otherwise. In JXTA 1.0, relays worked with HTTP only, so TCP connection could be considered as unnecessary overhead. However, JXTA 2.0 allows relays to use TCP, but this does not seem to be the optimal solution.

V. RELATED WORK Some of the existing p2p solutions are not built with high performance and scalability in mind [8]. This has prompted research into the performance, scalability and characterization of p2p systems. Such work includes analytic and simulationbased performance modeling [9] and measurement studies based on network crawling [8] and traffic tracing [10] of the Gnutella networks. A p2p traffic characterization study was 5

based on a campus-level trace of several content delivery networks [11]. The available results show a large heterogeneity of peers in terms of network bandwidth, lifetime, amount of shared data and willingness to cooperate. Such findings demand that future p2p applications and protocols, including JXTA, be designed to provide good performance, high scalability, and adaptation to heterogeneous environment. The efficient search and discovery in p2p overlay networks is addressed by distributed hash-table (DHT) schemes, such as CAN, Chord, Pastry, and Tapestry [12]. JXTA networks are going towards the hybrid DHT model in the protocol version 2.0, as compared to the Gnutella-like query flooding approach used in version 1.0 [13]. Performance measurements are available for components of early releases of JXTA, and mostly in the context of a particular application [2], [14], [15]. The first study of JXTA specifically targeting the pipe performance considered the environments of different types of pipes, earlier JXTA versions and the operating systems [16]. Earlier results indicate that a broad and more detailed performance study is needed. The JXTA community initiated a dedicated “Bench” sub-project, with a purpose to collect performance and scalability measurements as the platform development progresses [17]. The results of the various measurements are published on the project web site [17] in the form of the progress summary over the platform releases. The majority of the information is targeted towards the platform developers. The emphasis is put on the measurements of the pipes under message loads and rendezvous search and discovery performance, showing progress or regression over JXTA releases. The test results are from a controlled environment. This paper extends the investigation of pipes in a variety of peer configurations on a real LAN. In addition, the behavior of the JXTA pipes is characterized for different message sizes and compositions.

restart the platform frequently need a good combination of JXTA and JVM versions for better user experience. Some applications may find it highly beneficial to switch to the latest JXTA release if they engage in frequent exchange of small secure messages. JXTA is an infrastructure-rich p2p platform and its complexity allows many factors to impact its performance and scalability. The results of this and earlier works seem to just begin scratching the surface of the knowledge about JXTA. The evaluation of JXTA pipes under load and measurement of message and data throughput are the next step of the future work, which would provide a more complete understanding of the JXTA messaging sub-system. Further, the evaluation of the rendezvous and relay peers’ behavior in large peer groups is necessary to complete the performance and scalability picture of JXTA.

REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

VI. CONCLUSION AND FUTURE WORK The measurements of the JXTA implementations for the Java 2 Standard Edition show a significant difference in performance under different JVM versions and JXTA releases. The analysis of the results shows that under certain conditions, newer JXTA release has better peer startup time, as well as secure message transfer, multicast message propagation and handling of variety of message compositions. However, the performance of some components and features regressed, such as the unicast pipes for large messages and propagate pipes over TCP. These results indicate that improvements in some components do not necessarily indicate the overall benefit of the newer versions and that all relevant features need to be evaluated before the major version upgrade on a deployed system. Depending on the type of p2p application, some features of JXTA may be very important, whereas other may be irrelevant for the user. For example, applications that require the user to

[12] [13] [14] [15] [16] [17]

6

W. Nejdl, B. Wolf, S. Staab, and J. Tane, "EDUTELLA: Searching and Annotating Resources Within an RDF-based P2P Network," presented at Semantic Web Workshop, Hawaii, 2002. E. Halepovic and R. Deters, "Building a P2P Forum System with JXTA," presented at P2P '02, Linköping, Sweden, 2002. "Project JXTA Solutions Catalog," http ://bench.jxta.org/ project/www/ Catalog/index-catalog.html "Project JXTA Community Home Page," http://www.jxta.org/ B. Traversat, M. Abdelaziz, M. Duigou, J.-C. Hugly, E. Pouyoul, and B. Yeager, "Project JXTA Virtual Network," http: //www.jxta.org/project/ www/docs/JXTAprotocols_01nov02.pdf "Project JXTA:Java™ Programmer ’s Guide," http://www.jxta.org/docs/jxtaprogguide_final.pdf "JXTA v2.0 Protocols Specification," http ://spec.jxta.org/ nonav/v1.0/docbook/JXTAProtocols.html M. Ripeanu, A. Iamnitchi, and I. Foster, "Mapping the Gnutella Network," in IEEE Internet Computing, vol. 6, 2002, pp. 50-57. K. Kant and R. Iyer, "A Performance Model for Peer to Peer File Sharing Services," http://citeseer.nj.nec.com/kant01performance.html S. Saroiu, K. Gummadi, and S. Gribble, "A Measurement Study of Peerto-Peer File Sharing Systems," presented at MMCN '02, San Jose CA, USA, 2002. S. Saroiu, K. Gummadi, R. Dunn, S. Gribble, and H. Levy, "An Analysis of Internet Content Delivery Systems," presented at OSDI '02, Boston MA, USA, 2002. D. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins, and Z. Xu, "Peer-to-Peer Computing," HP Laboratories Palo Alto HPL-2002-57, 2002. B. Traversat, M. Abdelaziz, and E. Pouyoul, "Project JXTA: A LooselyConsistent DHT Rendezvous Walker," http://www.jxta.org/project/www/docs/jxta-dht.pdf S. Baehni, P. T. Eugster, and R. Guerraoui, "OS Support for P2P Programming: a Case for TPS," presented at ICDCS '02, Vienna, Austria, 2002. M. Junginger and Y. Lee, "The Multi-Ring Topology - HighPerformance Group Communication in Peer-to-Peer Networks," presented at P2P '02, Linköping, Sweden, 2002. J.-M. Seigneur, G. Biegel, and C. Damsgaard, "P2P with JXTA-Java pipes," presented at PPPJ '03, Kilkenny City, Ireland, 2003. "JXTA Bench Project," http://bench.jxta.org/