Search This Blog

Quick Links

Featured in Openshift Developer Spotlight

As many of you would know, a few months back I have launched the ONE Knowledge Base, which is hosted on Openshift. This week, my profile has been featured in the Openshift Developer Spotlight. Check out the mini-interview to learn why the ONE KB was developed and what problem it solves. Besides, you would also get to know about my favorite tools and development stack :)

If you have not tried the ONE KB yet, go for it now. Search the archives, and you might find that your question has already been answered!

Get link

Facebook

Twitter

Pinterest

Google+

Email

Other Apps

Labels

Comments

Post a Comment

Popular posts from this blog

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.

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…

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…