Skip to main content

Specifying Source and Destination of Messages

One of the frequently asked questions in the community is how to specify which particular nodes would act as source(s) and destination(s) of the messages created in the ONE simulator. The simulator, in fact, provides a pair of settings (shown below in bold face) aimed for this particular purpose.

Let us consider that there are $n + 1$ nodes in an OMN.  Further, let the nodes with addresses from $x$ to $y$, both inclusive, would create messages. The nodes in the range $w$ to $z$, both inclusive, would be the destinations of those messages, where $0 \le x \le y \le n$, and $0 \le w \le z \le n$. Then, the corresponding simulation scenario can be configured as follows.

## Message creation parameters

# How many event generators
Events.nrof = 1
# Class of the first event generator
Events1.class = MessageEventGenerator
# (Following settings are specific for the MessageEventGenerator class)
# Creation interval in seconds (one new message every 25 to 35 seconds)
Events1.interval = 25,35
# Message sizes (500kB - 1MB)
Events1.size = 500k,1M
# The source nodes -- nodes that create the messages
# Lower bound is inclusive; upper bound is exclusive
Events1.hosts = x, y+1
# The destinations of the messages created
# Lower bound is inclusive; upper bound is exclusive
Events1.tohosts = w, z+1
 # Message ID prefix
Events1.prefix = M

Note that the expressions $y + 1$ and $z+ 1$ should be replaced with their actual values. For example, if nodes $10$ to $20$ would create messages (both inclusive), and node $25$ is their destination, then the settings would like the following.

Events1.hosts = 10, 21
Events1.tohosts = 25, 26

Update: An alternative approach toward message creation is discussed in Juliano's blog.


  1. Excellent post Barun, this helped me :D! I tested yesterday, it was nice seeing the simulation nodes, through the GUI, and I saw only the two nodes I wanted "stacking up green and blue message blocks", this must mean it worked haha.

  2. thanks Barun, it's really flawless post.
    I have a question after doing this how do we know that message successfully send from source to destination ? please

    1. Hi,

      Not sure what you are asking. Are you talking about delivery of a message to its destination?

    2. Thanks dear Barun for your reply.
      yes, I want to know, does the message transfer from source to destination successfully or not
      for example : = 10
      Events1.tohost = 25
      how can I be sure that the message created by node 10 deliver to node 25?
      Thanks again

    3. It is hard to provide a guarantee that a given message would be delivered. Its delivery depends on several factors such as, routing protocol used, TTL, contacts, and others. Depending on your simulation parameters, in most scenarios, you would not get 100% delivery ratio.

      On the other hand, if your intention is that a source node should know of the delivered messages, you can use some form of acknowledgements. Alternatively, at each node maintain (and exchange) a list of messages received as destination. A source node would gather that knowledge at some later point of time.

    4. Thank you so much Sir, as usual, you explained very well.

  3. Thanks a lot for this tutorial. In this particular scenario,message is moving from 10 to 25, How could we get information which hop/nodes it is using as a relay node.

    Many Thanks in Advance..

    1. Hi Rashmi,

      The routing protocol would dictate which all nodes should be used as relays. E.g., in PRoPHET, a node with better delivery predictability can become a relay node.

      However, if you want to know which nodes have helped in replicating a copy of a message till now, you can use the getHops() method of the Message class.


Post a Comment

Popular posts from this blog

Effects of Buffer Size on Delay Tolerant Routing

In this post, we look at how buffer size affects, if at all, the performance of the routing protocols in DTNs. For this purpose, we will consider the following five routing protocols:
EpidemicPROPHETSpray-and-Wait (SnW) First Contact (FC) Direct Delivery (DD)  Detailed discussion of these protocols is scoped out here. We just note that in case of Epidemic, there is unlimited replication of the messages. In PROPHET, however, the replication is usually less than that of Epidemic. On the other hand, SnW has a fixed limit (L) on possible number of replications of a message. Finally, FC and DD involve message forwarding -- not replication. So, in the latter cases, there is always a single copy of any message in the DTN.

We will consider the buffer sizes from 20 MB to 180 MB, both inclusive, in steps of 20 MB so that we have total 9 different buffer sizes. We will use the real-life connection traces from Infocom'06. Therefore, we will need to simulate 5 * 9 = 45 scenarios to get the rel…

Controlling Transmission Range from within the Simulation

While simulating scenarios with the ONE simulator, one typically defines one or more network interfaces, and add them to the nodes as required. This use case prevails in most of the scenarios. However, a drawback here is that different network interfaces are mutually incompatible — an interface of type 1 can't communicate with any interface not of type 1.

Under certain circumstances, it might be required to control the transmission range of one or more network interfaces dynamically from within the simulation. For example, in one of my works, "On emotional aspects in Mission-Oriented Opportunistic Networks", I have considered the case where users occasionally turn off their device radios based on their contemporary emotions. In particular, the following shows how to set the radio range to 0: ModuleCommunicationBus comBus = host.getComBus(); // Store the original radio range the first time it is reset if (this.originalRadioRange == -1) { this.originalRadioRange = Double…