The project will be hosted here soon...
We implemented a simulation system in Java to evaluate the performance of various protocols. The basic architecture of the P2P simulator is based on a distributed, multi-threading, asynchronous, message passing environment. The peers exchange messages to build the overlay network and carry out search, insert/delete as well as join/leave operations. In our simulator, each peer is a thread executable task that can run independently. Every time a message is sent, a thread is assigned to the message's destination peer to serve that particular message. In order to avoid the thread creation overhead, thread competition, locking problems and etc, a thread pool with tunable number of threads is maintained. Furthermore, the simulator's ability to run over a grid adds even more realism to our experimental environment and overcomes the memory limitations.
The simulator has an unbiased and protocol independent mechanism to collect performance data. This mechanism is based on the observation and the filtering of special fields in the message. These fields are controlled by the simulator and are totally unaccessible from the protocol's processes. This alternative way to collect performance data, in conjunction with the realistic execution environment yields to more accurate results.
The key-features of this new simulator are:
Realism
Distributed
Unbiased
Pluggable
Extensible
Efficient
Practical
Portable
Figure 1: Standalone Architecture Design of the D-P2P-Sim.
Figure 2: Distributed Architecture Design of the D-P2P-Sim.
In this section are described the simulator's configuration files. There are two types of configuration files the simulator accepts as input. The first one defines the simulator's parameters and the second one defines the simulations' parameters. Both of them written in XML. Throughout this section we will describe each one in detail, using two sample configuration files.
Due to the fact that the configuration files are written in XML all the rules and standards defined by the XML should be followed faithfully when edit them!
Table 1: D-P2P-Sim's configuration file.
The "config.xml" file contains several tunable parameters regarding the simulator. The configuration file is divided in three parts: the cluster, the distribution and the misc. The cluster part describes the application node(s) that would be used to conduct our simulations. The distribution part describes the parameters of the distribution functions used by the simulator. Lastly, the misc part describes miscellaneous parameters.
The cluster part contains two different type of entries. The entry appNode defines a set of three parameters, id, ip and percent. The id is unique and identifies with the ip address the application node. The first application node should has id equal to 1, the second application node should has id equal to 2, etc. The ids should be sequential and unique. The ip parameter is the IP address of the application node. The percent is the percentage of peers that the application node hosts in each simulation. This parameter takes value between 1 to 100, and it's integer. The other entry appNodeId defines the Id of the application node that the configuration file resides. The value of this parameter is equal to the value of the appNode's id parameter, of the respective application node.
The distribution part contains three entries. The entry random defines only the parameter seed. This parameter is used as argument of the random methods, in order to be able to replicate the tests. The entry beta defines two parameters, alpha and beta. For the explanation of these two parameters read the javadoc. The entry powerLaw defines also two parameters, alpha and cut. For the explanation of these two parameters read the javadoc.
The misc part contains six entries. The entry inputFile defines the filename of the simulation configuration file. The entry threadPoolSize defines the number of threads in the thread pool. A simple rule for best performance is to have two threads for each CPU core. The entry debugLevel defines the log level. The set of valid values are defined in the javadoc. The entry logFile defines the filename of the log file, currently is not used and the output is printed to the standard output. The entry protocolsDir define the name of the directory where the protocols are stored. Lastly, the entry reportsDir defines the name of the directory where the reports are stored. Note, all the directories that are defined by the above entries should exist.
Table 2: D-P2P-Sim's simulation file.
The "simulation.xml" file defines the parameters of the simulation. For each simulation test is defined a block, called simulation. Each one of this simulation blocks contains eleven entries regarding the P2P protocol. The entry protocolName specifies the full name of the class that extends the abstract class d-p2p-sim.protocol.Peer. The entry protocolPackage specifies the jar's filename that contains the protocol's classes. The entry overlayPeers specifies the size of the P2P overlay network. The entry overlayKeys specifies the key capacity of the overlay network. The entry lookupQueries specifies the number of lookup queries performed after the construction of the overlay. The entry lookupDistribution specifies the distribution of the keys that are selected for the lookup queries. The entry insertQueries specifies the number of insert queries performed after the construction of the overlay. The entry insertDistribution specifies the distribution of the keys that are selected for the insert queries. The entry deleteQueries specifies the number of the delete queries performed after the overlay's construction. The entry deleteDistribution specifies the distribution of the keys that are selected for the delete queries. Lastly, the entry reportName specifies the report's filename.
Valid values for the *Distribution entries are: UNIF (uniform), BETA (beta) and POWL (power law).
Throughout this section is described the Graphical User Interface (Gui) of the D-P2P-Sim. The aim of the Gui is to drive someone easily through the simulation process without edit any configuration files or have any prior knowledge about simulation. Using the Gui someone can use almost all the simulator's capabilities. For example, the Gui is disabled when the simulator runs on distributed environment. But overall, it is a good point to start playing with the simulator. Below are described in detail each tab of the Gui.
Figure 3: Setup tab.
Figure 3 shows the first tab of the Gui. This tab, is called Setup, is used to create and destroy an overlay network. In order to create a new overlay it must be specified the number of peers in the field Number of Cluster Peers and the key capacity of the overlay in the field Number of Keys. To start the construction hit the top ok button. In order to destroy the overlay network, to clear the statistics and create a new one hit the bottom ok button. The construction progress is shown by the progress bar at the same tab.
Figure 4: Operations tab.
Figure 4 shows the second tab of the Gui. This tab, is called Operations, is used to test the lookup and update operations of the protocol. In order to be conduct one of these operations it must be specified in the field Cluster Peer the peer Id which fires the operation and in the field Key the key is being queried. To proceed hit the respective lookup, insert or delete button and watch the messages that are being exchanged between the peers in the text area. To clean up the messages hit the clear button. The specified values in the respective fields must agree with those inserted in the first tab.
Figure 5: Experiments tab.
Figure 5 shows the third tab of the Gui. This tab, is called Experiments, is used to evaluate the lookup and update operations of the protocol. In order to be conducted on of these experiments it must be specified in the field Number of Queries the number of queries that it will be performed, and in the field Distribution of Keys the distribution according to which keys are selected to be queried. To proceed hit the respective lookup, insert or delete button. After the process' completion select which result should be plotted and hit the plot button.
Figure 6: Plot that shows the performance of the lookup operation.
The figure 6 shows the performance of the lookup algorithm. In this plot the Y axis shows the number of hops needed by a lookup query to be answered while the X axis shows how many queries have been answered with a certain number of hops. This plot is created in the Experiments tab.
Figure 7: Statistics tab.
Figure 7 shows the fourth tab of the Gui. This tab, is called Statistics, is used to present online statistics regarding the overlay and its performance. In detail, the tab shows the size of the overlay (number of peers), the key capacity of the overlay (number of keys that can be stored), the average routing table of the peers, the average number of messages have been processed by each peer. Also, shows the total number of operations that have been conducted and the performance of the lookup and update algorithms. In the same tab the user can view the distribution of the load among the peers and export a report with all the statistical data.
Figure 8: Plot that shows the performance of the load balancing algorithm.
The figure 8 shows the performance of the load balanced algorithm. In this plot the Y axis shows the number of messages that have been processed by a peer while the X axis shows how many peers have processed a certain number of messages. This plot is created in the Statistics tab.
In this section are presented the instructions that should be followed to run experiments with the D-P2P-Sim simulator. The D-P2P-Sim requires Java Runtime Environment, version 1.6 or above, and a proper configured LAN if it is supposed to run over a LAN. Note, for those who use Linux distribution make sure that there is a line with the following format "IP FQDN HOSTNAME" in the "/etc/hosts" file, otherwise the RMI library fails.
There are three steps that should be followed in order to run tests with the D-P2P-Sim.
- Download, copy and extract the package to each machine that will be used for testing.
- Adjust the sample configuration files to your needs.
- Execute the d-p2p.sim.jar
To start the simulator open a console and move to the directory where the package has been extracted. Then, execute the following commands:
AppNode-1:~# cd d-p2p-sim
AppNode-1: d-p2p-sim# java -Xmx1024m -Xms1024m -Djava.security.policy=java.policy -jar d-p2p-sim.jar <config file>
If the configuration and the simulation files are properly formatted, then it will be printed out on the screen something similar to the lines above.
Reading Configuration...done
Simulation --0--
Protocol.name gr.upatras.ceid.mmlab.NbdtStar
Protocol.package NbdtStar_Rainbow.jar
Overlay.peers 100
Overlay.keys 8100
Lookup.queries 100
Lookup.distribution UNIF
Insert.queries 100
Insert.distribution BETA
Delete.queries 100
Delete.distribution POWL
Report.name NbdtStar_Rainbow-sim-1
Initializing Simulator...done
Loading Protocol...done
Initializing Overlay...done
Running Insertion Test...done
Running Lookup Test...done
Running Deletion Test...done
Publishing Report...done
Stopping Simulation...done
The syntax of the command is:
d-p2p-sim [--gui] [configuration]
--gui Enables the graphical user interface (Available only on standalone environment)
configuration The simulator's configuration file (The default is the config.xml)
When the simulator is configured to run over a grid, the execution all of the simulator's instances with Id other than 1 should be started first. The simulator's instance with Id equal to 1 should be executed last.
Any questions, recommendations or remarks are more than welcome!
George Papaloukopoulos, Department of Computer Engineering and Informatics, University of Patras papalukg@ceid.upatras.gr
Spyros Sioutas, Department of Informatics, Ionian University sioutas@ionio.gr
Evangelos Sakkopoulos, Department of Computer Engineering and Informatics, University of Patras sakkopul@cti.gr