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