Part 4 - Turning it Into a Real Network¶
4.1 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.
The NED file will need a few changes. First of all, the
Txc module will
need to have multiple input and output gates:
[ ] turns the gates into gate vectors. The size of the vector
(the number of gates) will be determined where we use Txc to build
Here we created 6 modules as a module vector, and connected them.
The resulting topology looks like this:
In this version,
tic 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
handleMessage() whenever a message arrives at the node. It draws
a random gate number, and sends out message on that gate.
When the message arrives at
handleMessage() will delete the message.
You'll notice that this simple "routing" is not very efficient:
often the packet keeps bouncing between two nodes for a while before it is sent
to a different direction. This can be improved somewhat if nodes don't send
the packet back to the sender. Implement this. Hints:
cGate::getIndex(). Note that if the message didn't arrive via a gate but was
a self-message, then
4.2 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
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.
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.
We have created the channel by specializing the built-in
(built-in channels can be found inside the
ned package. Thats why we used
the full type name
ned.DelayChannel) after the
Now let's check how the
connections section changed.
As you see we just specify the channel name inside the connection definition. This allows to easily change the delay parameter for the whole network.
4.3 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.
First of all, we have to define two-way (or so called
inout) gates instead of the
output gates we used previously.
connections section would look like this:
We have modified the gate names so we have to make some modifications to the C++ code.
The special $i and $o suffix after the gate name allows us to use the connection's two direction separately.
4.4 Defining our message class¶
In this step the destination address is no longer hardcoded
tic -- we draw a
random destination, and we'll add the destination address to the message.
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
See Section 6 of the OMNeT++ manual for more details on messages.
The makefile is set up so that the message compiler, opp_msgc is invoked
and it generates
tictoc13_m.cc from the message declaration
(The file names are generated from the
tictoc13.msg file name, not the message type name).
They will contain a generated
TicTocMsg13 class subclassed from [
the class will have getter and setter methods for every field.
tictoc13_m.h into our C++ code, and we can use
any other class.
For example, we use the following lines in
generateMessage() to create the
message and fill its fields.
handleMessage() begins like this:
In the argument to handleMessage(), we get the message as a
However, we can only access its fields defined in
TicTocMsg13 if we cast
TicTocMsg13*. Plain C-style cast (
is not safe because if the message is not a
TicTocMsg13 after all
the program will just crash, causing an error which is difficult to explore.
C++ offers a solution which is called
dynamic_cast. Here we use
which is provided by OMNeT++: it tries to cast the pointer via
and if it fails it stops the simulation with an error message, similar to the
In the next line, we check if the destination address is the same as the
node's address. The
getIndex() member function returns the index
of the module in the submodule vector (remember, in the NED file we
declarared it as
tic: Txc13, so our nodes have addresses 0..5).
When you run the model, it'll look like this:
You can click on the messages to see their content in the inspector window. Double-clicking will open the inspector in a new window. (You'll either have to temporarily stop the simulation for that, or to be very fast in handling the mouse). The inspector window displays lots of useful information; the message fields can be seen on the Contents page.
In this model, there is only one message underway at any given moment: nodes only generate a message when another message arrives at them. We did it this way to make it easier to follow the simulation. Change the module class so that instead, it generates messages periodically. The interval between messages should be a module parameter, returning exponentially distributed random numbers.