tictoc lab report (1)
TRANSCRIPT
TICTOC1
The first simulation tutorial is tictoc1. a network that consists of two nodes. One of the nodes will create a packet, and the two nodes will keep passing the same packet back and forth. We'll call the nodes "tic" and "toc".
These are the steps for Tictoc1:
i. Firstly, create a new Omnet++ Project named tictoc1. ii. Then, create a topology file named tictoc1.ned. A topology file is a text file that identifies the
network's nodes and the links between them.
This code will be read from bottom up. Let’s translate this code.
Tictoc1 is a network, which is assembled from two submodules, tic and toc. tic and
toc are instances of the same module type called Txc1. We connect tic's output gate
(named out) to toc's input gate (named in), and vica versa. There will be a 100ms
propagation delay both ways.
Txc1 is a simple module type. Txc1 has one input gate named in, and one output
gate named out (simple ... { ... }).
iii. Then, implement the functionality of the simple module Txc1. The file name is txc1.cc
From this code, we can say that:
In initialize() we create a message object (cMessage), and send it out on gate out.
Since this gate is connected to the other module's input gate, the simulation kernel
will deliver this message to the other module in the argument to handleMessage(),
after a 100ms propagation delay assigned to the link in the NED file. The other
module just sends it back (another 100ms delay), so it will result in a continuous
ping-pong.
iv. Then, create a file named omnetpp.ini
v. After complete all the steps above, run the simulation. Press the run button to start the
simulation.
TICTOC2 (REFINING THE GRAPHICS, AND ADDING DEBUGGING OUTPUT)
In tictoc2 we will learn how to make the model look prettier in the GUI. We assign the "block/routing"
icon and paint it cyan for tic and yellow for toc. This is achieved by adding display strings to the NED file.
These are the steps:
i. Create a topology file named tictoc2.ned
ii. Create another file named txc2.cc
iii. Then, create a file named omnetpp.ini. After complete all the steps, launch the simulation.
Press the run button to start the simulation.
TICTOC3 (ADDING STATE VARIABLES)
In this step we add a counter to the module, and delete the message after ten exchanges.
These are the steps:
i. Firstly, create a topology file named tictoc3.ned
ii. Then, create a file named txc3.cc. We set the variable to 10 in initialize() and decrement in
handleMessage(), that is, on every message arrival. After it reaches zero, the simulation will
run out of events and terminate.
iii. Create another file named omnetpp.ini. After complete all the steps, launch the simulation.
Press the run button to start the simulation.
iv. Double-click on tic's icon, then choose the Contents page from the inspector window that
pops up. As you continue running the simulation, you can follow as the counter keeps
decrementing until it reaches zero.
TICTOC4 (ADDING PARAMETERS)
In this step you'll learn how to add input parameters to the simulation: we'll turn the "magic number" 10
into a parameter and add a boolean parameter to decide whether the module should send out the first
message in its initialization code (whether this is a tic or a toc module).
These are the steps:
i. Create a NED file named tictoc4.ned. Module parameters have to be declared in the NED
file. The data type can be numeric, string, bool, or xml.
ii. Create a file named txc4.cc
iii. Then, create another file named omnetpp.ini. Note that because omnetpp.ini supports
wildcards, and parameters assigned from NED files take precedence over the ones in
omnetpp.ini, we could have used Tictoc4.t*c.limit=5 or Tictoc4.*.limit=5 or **.limit=5 with
the same effect. The difference between * and ** is that * will not match a dot and ** will.
iv. Launch the simulation. Press the run button to start the simulation.
TICTOC5 (MODELING PROCESSING DELAY)
If we take a closer look at the NED file we will realize that tic and toc differs only in their parameter
values and their display string. We can create a new simple module type by inheriting from another one
and specifying or overriding some of its parameters. In our case we will derive two simple module types
(Tic and Toc). Later we can use these types when defining the submodules in the network.
i. Hold messages for some time before sending it back timing is achieved by the module
sending a message to itself (i.e., self-messages)
ii. We "send" the self-messages with the scheduleAt() function
iii. handleMessage(): differentiate whether a new message has arrived via the input gate or the
self-message came back (timer expired)
TICTOC6 (MODELING PROCESSING DELAY)
In the previous models, tic and toc immediately sent back the received message. Here we'll add some
timing: tic and toc will hold the message for 1 simulated second before sending it back. In OMNeT++
such timing is achieved by the module sending a message to itself. Such messages are called self-
messages (but only because of the way they are used, otherwise they are ordinary message objects).
These are the steps:
i. Create a NED file named tictoc6.ned
ii. Create a file named txc6.cc. We added two cMessage * variables, event and tictocMsg to the
class, to remember the message we use for timing and message whose processing delay we
are simulating.
iii. Then, create another file named omnetpp.ini. After complete all the steps, launch the
simulation. Press run button to start the simulation.
TICTOC7 (RANDOM NUMBERS AND PARAMETERS)
In this step we'll introduce random numbers. We change the delay from 1s to a random value which can
be set from the NED file or from omnetpp.ini. Module parameters are able to return random variables,
however, to make use of this feature we have to read the parameter in handleMessage() every time we
use it.
These are the steps:
i. Create a NED file named tictoc7.ned
ii. Create a file named txc7.cc
iii. Then, create an omnetpp.ini file. We'll assign the parameters in omnetpp.ini. You can try
that no matter how many times you re-run the simulation, you'll get exactly the same
results. This is because OMNeT++ uses a deterministic algorithm to generate random
numbers, and initializes it to the same seed. This is important for reproducible simulations.
iv. After complete all the steps, launch the simulation.
TICTOC8 (TIMEOUT, CANCELLING TIMERS)
In order to get one step closer to modelling networking protocols, let us transform our model into a
stop-and-wait simulation. This time we'll have separate classes for tic and toc. The basic scenario is
similar to the previous ones: tic and toc will be tossing a message to one another. However, toc will
"lose" the message with some nonzero probability, and in that case tic will have to resend it.
These are the steps:
i. Create a file named tictoc8.ned
ii. Then create another file named txc8.cc. The function of bubble() call in the code is toc'll
display a callout whenever it drops the message. So, tic will start a timer whenever it sends
the message. When the timer expires, we'll assume the message was lost and send another
one. If toc's reply arrives, the timer has to be cancelled.
iii. Then, create omnetpp.ini file. Launch the simulation.
TICTOC9 (RETRANSMITTING THE SAME MESSAGE)
In this step we refine the previous model. There we just created another packet if we needed to
retransmit. This is OK because the packet didn't contain much, but in real life it's usually more practical
to keep a copy of the original packet so that we can re-send it without the need to build it again. What
we do here is keep the original packet and send only copies of it. We delete the original when toc's
acknowledgement arrives. To make it easier to visually verify the model, we'll include a message
sequence number the message names. In order to avoid handleMessage() growing too large, we'll put
the corresponding code into two new functions, generateNewMessage() and sendCopyOf() and call
them from handleMessage().
These are the steps:
i. Create a file named tictoc9.ned
ii. Create a file named txc9.cc
iii. Lastly, create omnetpp.ini. Then, launch the simulation.
TICTOC10 (MORE THAN TWO NODES)
Now we'll make a big step: create several tic modules and connect them into a network. For now, we'll
keep it simple what they do: one of the nodes generates a message, and the others keep tossing it
around in random directions until it arrives at a predetermined destination node.
i. Create a file named tictoc10.ned. The NED file will need a few changes. First of all, the Txc
module will need to have multiple input and output gates. The [ ] turns the gates into gate
vectors. The size of the vector (the number of gates) will be determined where we use Txc
to build the network. Here we created 6 modules as a module vector, and connected them.
ii. Create a file named txc10.cc. In this version, tic[0] will generate the message to be sent
around. This is done in initialize(), with the help of the getIndex() function which returns the
index of the module in the vector. The meat of the code is the forwardMessage() function
which we invoke from handleMessage() whenever a message arrives at the node. It draws a
random gate number (size() is the size of the gate vector), and sends out message on that
gate. When the message arrives at tic[3], its handleMessage() will delete the message.
iii. Create omnetpp.ini file. Then, launch the simulation
TICTOC11 (CHANNELS AND INNER TYPE DEFINITIONS)
Our new network definition is getting quite complex and long, especially the connections section. Let's
try to simplify it. The first thing we notice is that the connections always use the same delay parameter.
It is possible to create types for the connections (they are called channels) similarly to simple modules.
We should create a channel type which specifies the delay parameter and we will use that type for all
connections in the network.
These are the steps:
i. Create a file named tictoc11.ned. Based on the figure below, as you have noticed we have
defined the new channel type inside the network definition by adding a types section. This
type definition is only visible inside the network. It is called as a local or inner type. You can
use simple modules as inner types too, if you wish.
ii. Then, create a file named txc11.cc
iii. Create omnetpp.ini file. After complete all the steps, launch the simulation.
TICTOC12 (USING TWO-WAY CONNECTIONS)
If we check the connections section a little more, we will realize that each node pair is connected with
two connections. One for each direction. OMNeT++ 4 supports two way connections, so let's use them.
These are the steps:
i. Firstly, create a file named tictoc12.ned. We have to define two-way (or so called inout)
gates instead of the separate input and output gates we used previously.
ii. Create a file named txc12.cc.
iii. Create an omnetpp.ini file. After complete all the steps, launch the simulation
TICTOC13 (DEFINING OUR MESSAGE CLASS)
In this step the destination address is no longer hardcoded tic[3] -- we draw a random destination, and
we'll add the destination address to the message.
These are the steps:
i. Create a file named tictoc13.ned
ii. Create another file named tictoc13.msg. The best way is to subclass cMessage and add
destination as a data member. Hand-coding the message class is usually tedious because it
contains a lot of boilerplate code, so we let OMNeT++ generate the class for us. The
message class specification is in tictoc13.msg.
iii. Create a make file named txc13.cc. The makefile is set up so that the message compiler,
opp_msgc is invoked and it generates tictoc13_m.h and tictoc13_m.cc from the message
declaration. They will contain a generated TicTocMsg13 class subclassed from cMessage; the
class will have getter and setter methods for every field.
iv. Create a file named omnetpp.ini and launch the simulation.
TICTOC14 (DISPLAYING THE NUMBER OF PACKETS SENT/RECEIVED)
These are the steps:
i. Create a file named tictoc14.ned
ii. Then, create a file named tictoc14.msg. Then, make another file named txc14.cc. To get an
overview at runtime how many messages each node sent or received, we've added two
counters to the module class: numSent and numReceived.
iii. Create an omnetpp.ini file and launch the simulation.
TICTOC15 (ADDING STATISTICS COLLECTION)
The previous simulation model does something interesting enough so that we can collect some
statistics. For example, you may be interested in the average hop count a message has to travel before
reaching its destination. We'll record in the hop count of every message upon arrival into an output
vector (a sequence of (time,value) pairs, sort of a time series). We also calculate mean, standard
deviation, minimum, maximum values per node, and write them into a file at the end of the simulation.
Then we'll use tools from the OMNeT++ IDE to analyse the output files. For that, we add an output
vector object (which will record the data into Tictoc15-0.vec) and a histogram object (which also
calculates mean, etc) to the class.
These are the steps:
i. Create tictoc15.ned file and tictoc15.msg. Then, create another file named txc15.cc.
hopCountVector.record() call writes the data into Tictoc15-0.vec. With a large simulation
model or long execution time, the Tictoc15-0.vec file may grow very large. To handle this
situation, you can specifically disable/enable vector in omnetpp.ini, and you can also specify
a simulation time interval in which you're interested (data recorded outside this interval will
be discarded). When you begin a new simulation, the existing Tictoc15-0.vec/sca file gets
deleted.
ii. Scalar data (collected by the histogram object in this simulation) have to be recorded
manually, in the finish() function. finish() gets invoked on successful completion of the
simulation, i.e. not when it's stopped with an error. The recordScalar() calls in the code
below write into the Tictoc15-0.sca file.
iii. Create omnetpp.ini file and launch the simulation. You can also view the data during
simulation. In the module inspector's Contents page you'll find the hopCountStats and
hopCountVector objects, and you can open their inspectors (double-click). They will be
initially empty -- run the simulation in Fast (or even Express) mode to get enough data to be
displayed.
TICTOC16 (STATISTIC COLLECTION WITHOUT MODIFYING YOUR MODEL)
We will re-write the statistic collection introduced in the last step to use signals. First of all, we can
safely remove all statistic related variables from our module. There is no need for the cOutVector and
cLongHistogram classes either. We will need only a single signal that carries the hopCount of the
message at the time of message arrival at the destination.
These are the steps:
i. Create tictoc16.msg and txc16.cc. We need to define our signal. The arrivalSignal is just
an identifier that can be used later to easily refer to our signal. Besides, we must register all
signals before using them. The best place to do this is the initialize() method of the
module.
ii. The last step is that we have to define the emitted signal also in the NED file. Declaring
signals in the NED file allows you to have all information about your module in one place.
You will see the parameters it takes, its input and output gates, and also the signals and
statistics it provides.
iii.
Now we have just realized that we would like to see a histogram of the hopCount on the
tic[1] module. On the other hand we are short on disk storage and we are not interested
having the vector data for the first three module tic 0,1,2. No problem. We can add our
histogram and remove the unneeded vector recording without even touching the C++ or
NED files. Just open the INI file and modify the statistic recording.
iv. Then, launch the simulation
CONCLUSIONS
• OMNeT++: discrete event simulation system
• OMNeT++ is a
– public-source,
– component-based,
– modular and open-architecture simulation environment
– with strong GUI support and
– an embeddable simulation kernel