Translation: chord implementation for peersim

1. Configuration File

This document explains how to write configuration files that can be executed in peersim network simulation. This is the content of the config-chord.cfg example

# Random. seed1234567890

Simulation. endtime10 ^ 6

Simulation. logtime10 ^ 6

Simulation. experiments1

Network. Size 5000

Protocol. truniformrandomtransport

{

Mindelay 0

Maxdelay 0

}

These rows are the standard descriptions in the peersim event-driven protocol:

The first line defines the seeds used to generate pseudo-random numbers (if you cancel the annotation, all simulation performances are the same, which is useful for debugging)

The second and third rows define the time used for the simulation end and result log.

Row 4 lab count

Number of nodes in the network on the fifth line

The last command creates a transmission protocol used to send messages between two nodes.

Protocol. mychordprotocol

{

Transport tr

}

This is where we define the core protocol that imitates the chord application behavior on each node. messages are exchanged through the transport protocol defined above.

Control. traffictrafficgenerator

{

Protocol my

Step 100:

}

Now we need to describe a control subclass, which will generate a query Protocol (the source and destination are randomly selected) for each predefined time step.

Init. createcreatenw

{

Protocol my

Idlength 128

Succlistsize 12

}

Before simulation, we must create a perfect chord network. The createnw class initializes each node by generating a chord identifier (randomly selected in the number of bytes specified by idlength), and other parameters (succlistsize is the size of the successor list.

Control. observermessagecounterobserver

{

Protocol my

Step 90000:

}

The last part of the basic execution required by the Protocol is the observer, which calculates the average number of hops in the search prefix. These results are printed at the time of each specified step.

Control. dnetdynamicnetwork

{

Add 20

Add-25

Minsize 3000

Maxsize 7000

Step 100000:

Init.0 chordinitializer

{

Protocol my

}

}

In order to test the Protocol (frequent addition and departure of nodes) in the church n condition, we use the control and dynamic network provided by peersin to describe the number of nodes that are added or left, the boundaries and step durations of the network dimension are defined. To allow our Chord protocol to accept new nodes in the network, each node must be initialized in the initialization line. Nodes that have become part of the chord node will be randomly selected to help the new node discover the subsequent and route table items. The execution of the Protocol (without considering the reliability, reliability, and Transport Layer) can result in a prediction: the maximum number of hops (a message must pass before reaching the correct destination) yes. Of course, these numbers must be an integer (so 12 and 29 are the boundaries of 13 hops). The average number of hops is predictable and low (remember: from a node to its own search will also happen ). These parameters are fixed: 128-bit ID length and route table items, 12 as the size of the successor list, 10 ^ 6 as the simulation time of about 9000 Message Processing in each test

2. Run the code

To run the configuration file, run the following command:

Java-CP peersim-1.0.3.jar: djep-1.0.0.jar: jep-2.3.0.jarpeersim.Simulator

Config-chord.txt

3. Results

To correctly determine behaviors, we must consider more parameters without considering the dynamic network (node failure, join, in particular, the number of calls to the stable method and the number of failures before reaching the destination (in this case, the message is discarded). The fixed parameter is 129 as the idlength and 12 as the size of the successor list, 5000 is the initial network size, 3000 and 7000 are the upstream and downstream network size. The execution time indicates that the simulation and dynamic control steps are set to 10 s. As you noted, the removal process of the ring is not critical. The number of failures is limited (so low that it does not appear in the figure), and the maximum number of hops is acceptable (15 instead of 13 ). Remember: The stability is the number of times the node calls stabilize (). It is executed every time the successor list or route is updated by the table (many times during each interaction), so this is highly predictable: during the simulation, the network scale is reduced or the original size is increased by 20%. When a node is added, we note that the number of failures will increase because the failure occurs between the node and its successor. When a message is sent to the corresponding chord
ID must be removed only when declared. So that we can assume that a message is generated from a node that fails at the same time. The problem is that in order to handle the added consistency, the initializer cannot definitely determine the successor of a node (performance will be too slow), but only one node is not far away, then, in each interaction, the new node will adjust its successor pointer to the node closer to the ring. Unfortunately, when many messages reach the processing process, if they reach the node between the new node and the next node, the message will be discarded. This explains that the number of node failures increases with the addition of nodes. However, in a longer simulation, the subsequent list will be adjusted until no more failures occur. The average and maximum number of hops are not considered as the same as those of the church.

Translation first, and further research after the National Day. You are welcome to discuss and make progress together. Add QQ: 185851486 (indicating P2P)