6.2.1 Test environment

Peer-to-peer networks are highly complex and heterogeneous because their size is not limited, and the equipments of peers differ greatly. In addition, peers have a dynamic and unpredictable character as they join and leave frequently. This complexity cannot be mirrored in a computer laboratory without enormous effort. One approach would be to use a simulation, but this prohibits comparing with existing products, which need a real network, not a simulation in order to operate. As our goal was to improve the group communication of JXTA, we need to compare our system to it, and this cannot be done with a simulation. Instead, we used a local network to evaluate the two systems. Although this does not reflect the peer-to-peer complexity, it shows how efficient a system is.

The tests were performed with seven identical computers. Each PC was equipped with a 1.7 GHz Intel Pentium 4 processor, 256 MB of RAM, and a 100 Mbit Ethernet adapter. Microsoft Windows 2000 was the operating system. The Java virtual machine was Sun’s Java 1.3.1, using the Client Hotspot mode.

6.2.2 JXTA

JXTA was discussed in chapter 2 before. It aims to provide an all-purpose peer-to-peer protocol. Although the protocol is platform and language independent, the reference implementation, which is used in the tests, is developed in Java. The tests were performed using JXTA 1.0, stable build 49b of February 2002. Each JXTA peer was running on a separate machine. One machine was running exclusively as a JXTA relay and did not participate in sending or receiving messages. The relay and the other peers were only connected with each other in the local network and did not join a JXTA Internet network.

6.2.2.1 Pipes and reliability in JXTA

JXTA’s communicate mechanism are based on “pipes”, which connect peers together and abstract from how messages are delivered by the peer-to-peer network. Besides unicast pipes, JXTA also offers a “propagate pipe” for multicasting a message to multiple peers, which listen to the pipe. This kind of group communication is very similar to the publish/subscribe concept. Standard JXTA pipes are by definition unreliable, reliable pipes are a type of its own. However, the propagation pipe is not reliable. This behavior could be observed during the tests, too. Table 1 shows that the loss rate was up to 80% at receiving peers. Only 20% of the sent messages were actually received. This observation was made independently from the number of receiving peers (one, three, or five). However, the message size influences the reliability as illustrated by the last entry in the table.

Table 1. JXTA’s unreliability: Number of sent and received Messages

Message Size
[Bytes]
Number of Sent Messages Number of Received Messages Message Loss Rate
1 5,000 1,000 80.0 %
10 5,000 1,040 79.2 %
100 5,000 980 80.4 %
1,000 5,000 1,040 79.2 %
10,000 5,000 1,920 61.6 %


Experiments showed that JXTA’s reliability depends heavily on the workload within a timeframe. The experiments are based on introducing a pause between sending messages. The results (Table 2) indicate that even a small pause improves reliability dramatically. These experiments were made with a single machine (866 MHz), which ran one rendezvous, one sender and one receiver peer. Thus, the values may not be comparable to the other ones, but the exact values are not important for this experiment. Only the observation that reliability suffers from a high workload is significant for our purpose. JXTA seems to discard messages when the high workload is high. However, we decided not to introduce a pause at the sender as this would have influenced the further experiments significantly. Instead, we measured the results based on the number of actually received messages.

Table 2. JXTA’s unreliability: Number of sent and received Messages

Pause
[Milliseconds]
Number of Sent Messages Number of Received Messages Message Loss Rate
0 1,000 480 52.0 %
10 1,000 984 1.6 %
20 1,000 995 0.5 %
30 1,000 998 0.2 %
40 1,000 1,000 0.0 %

Another observation was that JXTA does not handle message with a size greater than 10,000 bytes. We could not perform the tests with a message size of 100,000 bytes with JXTA. The sending process was successful, but the receivers did not receive any messages.

6.2.2.2 Results

Table 3. JXTA: one receiving peer

Message Size
[Bytes]
Sender
[Messages/Second]
Receiver
[Messages/Second]
1 369 81
10 368 80
100 368 80
1,000 346 79
10,000 244 75

Table 4. JXTA: three receiving peers

Message Size
[Bytes]
Sender
[Messages/Second]
Receiver
[Messages/Second]
1 357 75
10 361 75
100 360 73
1,000 340 75
10,000 195 62

Table 5. JXTA: five receiving peers

Message Size
[Bytes]
Sender
[Messages/Second]
Receiver
[Messages/Second]
1 352 71
10 333 70
100 335 70
1,000 295 68
10,000 143 56

(C) Copyright 2002 Markus Junginger. All rights reserved.

Comments: mj@j3d.de

Homepage: www.j3d.de