home  /  howto  /  faq  /  mailing list  /  screenshot  /  contact
PDOS  /  CSAIL  /  MIT

p2psim: chord faq

What are the different variations of Chord in the simulator?
If you want to simulate Chord, please use the most actively supported and tested implementation: ChordFingerPNS.

There are 3 classes: Chord, ChordFinger, and ChordFingerPNS. Chord is the base class for all Chord variations, supporting only a successor list with no fingers. ChordFinger implements the original SIGCOMM Chord, it keeps (b-1)*log_b(n) immediate fingers where b is the base. ChordFingerPNS is the proximity-aware Chord,;it keeps (b-1)*log_b(n) PNS fingers. A node chooses its PNS finger by picking the node closest to itself from the corresponding immediate finger's successor list. ChordFingerPNS is described in the NSDI'04 paper.

For more information on the Chord protocol itself, please refer to the documentation of the Chord Project.

How do I run ChordFingerPNS?
The same way you run any other protocols in p2psim. For example, you can make use of the scripts/run-simulations.pl script to run Chord with various parameter values.

scripts/run-simulations.pl --protocol Chord --topology your_favorate_topology_file --logdir . --args examples/chord_args
All protocol and event parameters are specified in examples/chord_args and the logs files will be generated in the current directory.

What parameters can I pass to Chord?
Please refer to examples/chord_args For example, a typical chord protocol args file contains the following:

ChordFingerPNS base=2 successors=16 pnstimer=2000000
   basictimer=2000000 succlisttimer=2000000 m=1 allfrag=1 recurs=1 maxlookuptime=0 initstate=1
(Note: this should be a single line!)

base: determines the base of the fingers, it determines how much state ChordFingerPNS keeps (b-1)*log_b(n)
pnstimer: how often ChordFingerPNS stabilizes its PNS fingers
basictimer: how often Chord stabilizes its successor and predecessor
succlisttimer: how often Chord stabilizes its successor list
m=1: the lookup is for the immediate succecessor of the key only
allfrag=1: only the immediate successor should be returned
(NOTE: always set m=1 allfrag=1, other values are not supported at the moment)
recurs=1: performs recursive lookup, (if 0, performs iterative lookup)
maxlookuptime: this determines when to give up after repeatedly getting incorrect lookup results when retrying. if maxlookuptime = 0, it means no lookup retry is performed.
initstate=1 when all nodes are started at the same time in the beginning of the simulation, initialize their successor list and finger table with global knowledge. Otherwise, it takes quite a while for Chord nodes to converge to correct routing state when everybody starts out at the same time.