Skip to main content

4. DHTTestApp & DHT

DHTTestAPP & DHT work together where DHTTestAPP utilizes the DHT to store & retrieve (key, value) pairs. DHT utilize the underlying overlay to route queries.

Is a Tier2 application that periodically issue DHT put, get, & modify queries. The implementation consist of 2 modules:
  1. GlobalDhtTestMap - Provides a data structure & functions to maintain a global list of (key, value) pairs. Random keys are taken from this list to issue DHT get & modify queries.
  2. DHTTestApp - Issues DHT put, get, & modify queries after some delay derived from a truncnormal distribution. 
  • Put messages - Use to add a random (key, value) pair into the DHT. A put message (represented as DHTputCAPICall) consists of a random key, random value, expiration time (ttl), & whether (key, value) pair can be modified. Then the message is send to the Tier1 application using sendInternalRpcCall() method, which will store (key, value) pair in the DHT. When a successful response is received (key, value) pair is added to the GlobalDhtTestMap.
  • Get messages - Pick a random key from the GlobalDhtTestMap & then issue a DHT get query to the Tier1 application using DHTgetCAPICall() method. Tier1 application sends the appropriate value if it exists. If the key's validity has expired delete it from GlobalDhtTestMap otherwise consider get query as success.
  • Modify messages - Pick a random key from the GlobalDhtTestMap & then issue a DHT put query to the Tier1 application. DHT entries are modified using a put message that will place an updated version of the (key, value) pair into DHT.
Maintain the DHT with the support of the underlying overlay. The implementation consist of 2 modules:
  1. DHTDataStorage - Provides a data structure & functions to maintain DHT storage of a node.
  2. DHT - Capable of storing & retrieving multiple (key, value) pairs (e.g., same file in multiple peers) given that they have distinct kinds or IDs. Each entry has an expiration time & removed from the DHT when it expires.
sendInternalRPCCall() is used to communication between DHTTestApp  & DHT using DHTputCAPICall & DHTgetCAPICall messages.


Thanks... you have a great blog! I'm new to both OMNet++ and OverSim. It seems that DHTTestApp is an application layer on top of DHT. But how can I change the underlying overlay (Chord, Pastry, Kademila, etc)? Is DHT a common interface to those underlying overlay implementations such as Chord, Pastry, etc?
Dilum Bandara said…
Yes. Interface is common & should work with any strutured P2P.
You can set it using **.overlayType in omnetpp.ini. For e.g.,
**.overlayType = "oversim.overlay.mychord.MyChordModules"
Here I use modified version of Chord called 'mychord'
Then you need to set other relevant parameters for your overlay. See examples on omnetpp.ini & default.ini
Alban said…
Hello, I'm a french student working on Kademlia, and I need to make an application based on DHTTestApp where only one node (the first created for exemple) publish N pairs (N Put request). And I need to mesure the latency of these N publications. How can I "select" only one node to do that ?
Thank you.
Anonymous said…

Popular posts from this blog

Python Code to Calculate Gini index/coefficient, Robin Hood index, & Lorenz curve

Following Python code can be used to calculate Gini index, Gini coefficient, Robin Hood index, and points of Lorenz curve. Lorenz curve can be also plot if matplotlib is installed.
It's based on the steps given by Peter Rosenmai.


Other online tools:

1. Building P2P Simulators with OverSim - Where to Begin

This could be a series of blog posts about extending or developing your own OverSim applications & overlay networks. OverSim has a minimal tutorial on writing your own application & overlay network; however, it doesn't show the big picture. So, I'm wasting lots of time playing with code & trying to understand the rest. Good thing is, I like it more & more as I understand. You need to change/develop only a few things, but finding out which ones is a hell of a task. I hope this will not only make my life easy but also will be useful to new comers. Here's what you need to do: You need some background on OMNeT++ OverSim extend OMNeT++. But sometime it has its own way of doing things (to make your task even simple) so understand the differences.Develop several OMNeT++ simulators. TicToc is a good one to start with. Extend it as you imagine.Read Towards a Common API for Structured Peer-to-Peer Overlays, which is the basis for OvseSim's API. Here'…

Describing Experimental/Simulation Setup

Sometimes the results of a performance analysis may depend on the computers used and/or specific features of software/libraries. In such cases it is extremely important to describe the experimental/simulation set up in details. It enables others to repeat those experiments as well as check whether the results are rigorous, statistically sound, and unbiased. Unfortunately, "Simulation Setup" is the shortest section in many research papers where authors try to save space by cutting down as much as details. Here are some tips on what to include (in addition to describing the experimental/simulation setup) based on my experiences:
Type of Simulation Are the results based on Experimentation, Emulation, or Simulation? If simulations also mention further details like whether it is Discrete Event, Montacarlo, Stochastic, or Deterministic simulation. Are the results for Steady, Dynamic, Starting/ramp-up, or Terminating state(s)?Number of Experiments/Simulations No of sampl…