Exploring messages

OMNeT++ has some very powerful tools to log information during a simulation and to analyze it later. Let's add the following line to the omnetpp.ini file:

record-eventlog = true

This is to log information about all events in the simulation. Now, run the simulation until the end, then go to your results folder (simulations/) and double-click on the .elog file. The event sequence chart will open. Left-click on the chart to select zoom / to fit. What you see is something similar to this:

What you see, are all events for both nodes. Now it is time to step back and to reflect a little bit on the meaning of this. We have two nodes, which have an identical implemented behavior, running side by side, and their event timings are very different. We also see that all events are only self messages - they start and end at the same node (the Y axis). The difference comes from the random scheduling of the messages - if you remove that, you will end up with identical behaviors.

The fact that several nodes have the same implementation, but do different things, controlled by messages and their arrival times, is sometimes a little bit confusing for novices in discrete event simulation. You need to observe each node separately but implement a common behavior. 

Question: When you have two events scheduled at exactly the same time, how does the kernel decide which one to fire first?

This is a very important question! The kernel keeps an ID for each module in the simulation - the network itself and all simple and compound modules. You can see those when the simulation is running: 

The network got ID1, the two nodes IDs 2 and 3. Be careful: you cannot control these IDs and should NEVER use them in your implementation for addressing your nodes or modules. However, the kernel will use those to order the events by their creator's ID. For example, if you have two events scheduled at time 10 from node IDs 2 and 3, first the event of ID 2 will be fired. There is no randomness here because we require REPEATABILITY when we re-run exactly the same simulation again. Differently from implementing randomness as we did before, we would like to be able to switch any randomness completely off, mostly for debugging reasons.

Let's see now to send messages to each other.