Skip to main content

2. OverSim - First Application & Overlay

OverSim has many sample applications & overlays that you can look at & understand. But, it's always better to build your own ones so you would understand things better. OverSimDevelop provides the steps necessary to build your first application & overlay. My objectives it to provide few additional details that would complete the picture.

A node generates a ping messages & sends it to a randomly selected node. When the destination node gets the ping message, it replies with a pong message. As this process continuous messages are probabilistically dropped & statistics are collected.

MyApplication randomly selects set of overlay nodes then send a ping message to each of them using the MyOverlay. Each overlay node maintains 2 pointers, one to the successor & another to the predecessor node. Ping messages are forwarded clockwise or anticlockwise based on these 2 pointers, e.g., message from node 8 to 2 (in a network with 10 nodes) will follow the path 8 → 7 → 6 → 5 → 4 → 3 → 2 (it will not take the path 8 → 9 → 0 → 1 → 2). The destination node directly (using an UDP connection) replies back to the sender, when it receives the ping message. After receiving its own ping, source node records statistics & then drop the ping message. If desired, ping messages can be dropped while they are being forwarded.
The application is dependent on SimpleUnderlayNetwork and default routing (i.e., iterative routing) as defined in default.ini file. Later, RPC messages are used to discover set of neighbors of a given node.

  • Periodically selects a random set of nodes then sends a ping message to a each of those nodes
    • A message contains a type (i.e., ping) & senderAddress
  • When a message reaches the destination, the receiving node changes the message type to pong & send directly to the sender based on the senderAddress indicated in the ping message.
  • ping messages are delivered through overlay while pong messages are delivered directly through a UDP connection.
    • In the underlay level, even the overlay messages are delivered as UDP messages.
  • Application binds to a UDP port because it receives UDP messages
  • When a pong message is received, the sender update message counter then delete the message
  • Join the overlay & establish a pointer to successor & predecessor
  • Forward messages
    • Determine a potential next hop node based on overlay routing scheme, which is either through successor or predecessor
  • Drop messages based on a given probability. Don't tell a next hop in the forward() method ,if message is being dropped
  • Node's IP address is derived from its key & has the format 1.0.0.key
  • Count the number of dropped messages
  • Message delivery latency is calculated based on the distance between the 2 nodes on a 2D plane & packet size
  • Has a message type, 1 for ping & 2 for pong
  • Include the address of the sender so that pong message can be send directly using UDP
  • RPC messages are used to request set of neighbors of a node & to reply with list of neighbors
Next Step
Extend MyOverlay & MyApplication to provide more functionality such as:
  • Modify joinOverlay & findNode methods to support a circular address space & bidirectional routing
  • Track hop count for messages & verify different routing types in OverSim
  • Keep points to nodes that are faraway (2 or 4-hops) then observe reduction in hop count
Then you can play with the KBRTestApp.


Anonymous said…
Sorry for my bad english. Thank you so much for your good post. Your post helped me in my college assignment, If you can provide me more details please email me.
Dilum Bandara said…
What specifics you want to know? Also how to respond without e-mail address?
Anonymous said…
thank you for your all useful posts about OverSim. But i cannot undestand how KBR routing works for the example MyOverlay. The type is defined as "iterative" but the program defines a new protocol which is not implemented.
Thank you in advance.
Dilum Bandara said…
Could you be more specific, I didn't understand question...
indraneel said…
Your blog is like God Gift for people like me. Could you please guide me to the very basic level of new development in OverSim. I am new to OverSim environment.

Popular posts from this blog

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'…

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:

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…