Universität Karlsruhe (TH)

Institut für Telematik

T ELE M ATICS T ECHNICAL R EPORTS

Integrating real world applications

into OMNeT++

Christoph P. Mayer, Thomas Gamer

{mayer,gamer}@tm.uka.de

February, 27th 2008

TM-2008-2
ISSN 1613-849X
http://doc.tm.uka.de/tr/

Institute of Telematics, University of Karlsruhe

Zirkel 2, D-76128 Karlsruhe, Germany
 Integrating real world applications into OMNeT++

Christoph P. Mayer Thomas Gamer

Institut für Telematik Institut für Telematik
Universität Karlsruhe (TH) Universität Karlsruhe (TH)
Germany Germany
[email protected] [email protected]

ABSTRACT Thus, such attacks can be detected efficiently and as early

The discrete event simulator OMNeT++ is nowadays used as possible. The behavior of such an application in large
for network simulations in the majority of cases. Unfortu- networks and under varying conditions may be more eas-
nately, it is not possible to easily integrate real world net- ily evaluated using a network simulator than a real network.
working applications into simulation models. This, however, Thus, an easy integration of real world applications into sim-
would enable less complex and more efficient development ulators should be possible without the need for redesigning
and evaluation of real applications, especially of those that or re-implementing them for the OMNeT++ environment.
work in a distributed manner, in comparison to an evalu-
ation in real world networks. We therefore present in this If networking protocols are implemented for usage with
paper approaches to overcome the shortcoming of real world OMNeT++ protocol logic typically is integrated into so
application simulation in OMNeT++ and discuss problems called simple modules using C++ code. By combining mul-
and solutions that arise in this context. Our preferred ap- tiple simple modules into a compound module it is possible
proach for integrating real applications into simulation mod- to implement more complex application logic, too. Thus,
els is based on an encapsulation of real applications as shared additional client and server applications can be integrated
libraries that can be dynamically loaded by OMNeT++ at into the simulation model, e. g. in order to generate realistic
runtime. background traffic. Integrating already existing real world
applications into OMNeT++ simulations, however, is not
as easy as implementing new applications specifically for
Categories and Subject Descriptors OMNeT++. Problems arise, for example, if threads are
I.6.3 [Simulation and Modeling]: Applications
used in real world applications. In addition to the complex-
ity of actually integrating real world applications, serious
General Terms simulation runtime problems may arise. These could result
Application simulation in time distortion, CPU scheduling issues, and process or
symbol space problems.
Keywords
Previous work mainly focused on the integration of real
OMNeT++ integration, hardware-in-the-loop, real world
world TCP/IP network stacks into OMNeT++ or other
simulation, application model
network simulators [2, 8]. The overlay network simulation
framework OverSim [1] uses socket connections to connect
1. INTRODUCTION external applications to the simulation model. We are, how-
When it comes to network simulation researchers often rely ever, not aware of further work that details challenges and
on the OMNeT++ simulation environment [13]. Due to its solutions of easily integrating existing real world applica-
powerful discrete event simulation engine and lots of avail- tions into OMNeT++.
able network protocols it is very easy to simulate and eval-
uate networking protocols and applications using e. g. arbi- The rest of the paper is organized as follows: Section 2 fur-
trarily large and complex network topologies [5]. ther motivates the need for integrating real world applica-
tions into OMNeT++. Different approaches for an integra-
The integration of existing real world applications into sim- tion of such applications – socket connection, source code
ulators like OMNeT++ notably simplifies evaluation and integration, and shared library integration – are discussed
further development of these applications since topologies, and compared in section 3. We consider usage of shared
traffic patterns, and other parameters can be changed eas- libraries the best method for integrating real world appli-
ily within a simulator. This is even more important in case cations into a simulation model. Therefore, this method is
of distributed applications, e. g. distributed anomaly-based presented in more detail in section 4. Additionally, neces-
attack detection [6]. The detection systems in this example sary adjustments that have to be made on applications as
are sparsely distributed on nodes within the network. Spe- well as OMNeT++ are explained in detail. Section 5, then,
cific information, e. g. statistical traffic distributions which details the problems that arise at compile time and runtime
are locally measured, is communicated between various in- and describes solutions. Finally, section 6 gives a short sum-
stances in order to improve detection of adverse events like mary and an outlook on future work.
distributed denial-of-service attacks or worm propagations.
2. WHY INTEGRATE? for such an integration: socket connection, source code in-
Evaluating real world applications – especially distributed tegration, and using shared libraries. Additionally, we will
applications – based on real networks is a challenging task. evaluate the complexity and applicability of each suggested
Keeping the previously described example of distributed approach.
anomaly-based attack detection in mind, a real network
must achieve several requirements in order to be usable for The socket connection (see section 3.1) is e. g. used by the
evaluation: OverSim framework [1] in order to connect real world ap-
plications like SIP clients to the simulation model. Direct
source code integration (see section 3.2) is the default way to
1. A large network is necessary in order to get meaningful integrate protocol and application logic into
evaluation results. OMNeT++ [15]. Using dynamically loadable shared libraries
(see section 3.3) to outsource application code is partially
2. Control over all nodes in the network is needed, e. g.
documented in [14, 15].
to deploy the attack detection system or to execute a
distributed denial-of-service attack.
3.1 Socket connection
3. A realistic network environment including e. g. a real- Connecting a real world application to the simulation us-
istic topology and realistic background traffic is needed. ing a socket has been implemented e. g. by OverSim and is
documented in the OMNeT++ sockets sample [13]. It re-
quires a simple module acting as proxy within OMNeT++.
These requirements apply to most distributed applications. This proxy maintains a socket connection with the real world
Creating a large testbed for evaluation, however, results in application. This method often does not imply any source
high efforts for deploying necessary applications – attack de- code changes on the application and thus, is very easy to
tection as well as attack execution in our example – on dif- implement.
ferent hosts in the network. Furthermore, building up such
a large network – maybe consisting of hundreds or thou- Socket connections can be used if an application has no need
sands of nodes – involves high costs for hardware. The need for lower layer protocols but just needs data from applica-
for different network topologies and varying network condi- tion layer. Anyway it is also possible to tunnel the whole
tions additionally increases the expenses and administrative network packet including all lower layers over the socket.
efforts. Furthermore, clients – and possibly human users – In most cases this requires source code adaptations on the
and servers have to be deployed in the network in order to application to support tunneling of network packets. This
create realistic background traffic. means that it is not possible to, e. g., transparently connect
an intrusion detection system (IDS) that uses a Libpcap [7]
Another possibility is to use an existing large network for interface for packet capture to an OMNeT++ simulation
evaluation of real world applications, e. g. PlanetLab [9] using a socket connection.
which provides control over the nodes. This ensure that no
additional hardware has to be deployed and thus, reduces Despite the fact that the integration using a socket connec-
costs significantly. If such a network, however, is used it tion is quite easy to perform, it suffers from the following
must be ensured that the evaluation does not disrupt nor- problems:
mal network operation and that failure or malfunction of the
network does not bias evaluation results. Therefore, such an
operational network can not be used in case of an attack de- 1. CPU scheduling issues
tection system since attacks would disrupt normal network
operation but must be generated explicitly in order to get 2. Synchronization issues
meaningful evaluation results.
Since an OMNeT++ simulation typically runs as fast as pos-
All of the mentioned requirements can be easily fulfilled sible it consumes as much CPU time as possible. This results
when deploying existing real world applications in a sim- in the first problem: The external application may not get
ulation environment like OMNeT++. Creating arbitrarily enough CPU time for its own operations and therefore, does
large network topologies is provided by topology generators not run smoothly (1). In order to avoid this issue higher
like ReaSE [5]. They furthermore allow creation of vary- process priorities may be assigned to the real world applica-
ing network topologies. Control over the network is always tion. This, however, may result in problems for OMNeT++
given when running simulations, thus the second require- if traffic sent by the application can not be processed fast
ment does not impose a problem, too. In order to achieve enough and thus, causes the socket connection to break.
a realistic environment self-similar network traffic [16] must
be generated. Additionally, malicious nodes have to be in- OMNeT++, on the one hand, performs a time discrete sim-
tegrated into the simulaton, e. g. based on the Tribe Flood ulation in its own time domain: the simulation time. An
Network [4] DDoS tool as shown in [5], which execute DDoS application that is connected to a simulation using a socket
attacks. connection, on the other hand, runs in its own time domain:
the wall clock time which runs in real time. This causes
3. INTEGRATION METHODS time distortion between simulation and real world applica-
There are different approaches that can be used in order tion that leads to inaccurate or even false simulation re-
to integrate real world applications into OMNeT++ simula- sults (2). The solution that is implemented by OMNeT++
tion models. In this section we will describe three techniques and OverSim is to use a special simulation scheduler that
slows down the simulation to real time. This causes both As OMNeT++ pursues a discrete simulation model the use
the simulation and the external application to run in the of threading (4) causes problems (see section 5.1). This is
same time domain, i. e. the wall clock time. a general problem that is not only related to the approach
of source code integration. Furthermore, timer mechanisms
This approach, however, results in further problems that must be considered: Total timer functionality has to be em-
may bias the simulation results. First of all, the approach ulated by using OMNeT++ self messages (see section 5.2).
to slow down the simulation is only possible if the simula-
tion is able to run faster than real time. Depending on the
number of modules used in the simulation and on generated 3.3 Shared library integration
traffic between the hosts in the simulated network this re- Another possibility to integrate applications into OMNeT++
quirement must not taken for granted in all cases. Secondly, is to include binary code. We call this method shared library
the external application is still not running in a time dis- integration. It is quite similar to the integration of source
crete manner and therefore, may not be synchronized with code and involves most of its integration steps. As huge
the simulation properly. The last drawback of slowing down advantage the Shared library integration avoids the most
the simulation is the extended simulation time: Executing challenging problem: project build management.
a simulation that normally runs ten times faster than real
time and provides ten hours of simulation time will end up Whereas the source code integration requires major adap-
running for ten hours real time instead of just one if socket tations to the OMNeT++ build environment the approach
connections are used for the integration. of using shared libraries keeps the build environment for the
real world application and OMNeT++ separated in a sound
3.2 Source code integration way. Compile and link time switches as well as external de-
Integrating source code directly into a simulation is the de- pendencies of the application can be retained. This enables
fault approach when evaluating protocols using OMNeT++. different compile and link time settings for OMNeT++ and
This involves writing simple modules in C++ and compil- the real world application. In the majority of cases a real
ing them using the OMNeT++ build environment. This world application uses compile and link settings that can
approach enables easy development of protocols and small not be changed without breaking the application. Thus the
applications. Since all code is implemented directly into Shared library integration enables the application to pre-
OMNeT++ and scheduled by OMNeT++ no time distor- serve its specific settings and integrate into OMNeT++.
tion can occur.
Changing the output type of an application to shared library
The direct source code integration technique suffers from the involves only small adaptations to the application build en-
following problems that make it difficult to integrate existing vironment that can be implemented e. g. using command
real world applications into OMNeT++: line flags for the GNU make build system [12]. This avoids
costly maintenance of multiple project build environments
for the application. Only one application build environment
1. Real world applications consist of multiple source files exists that can be used to build both the native application
and contain dependencies that have to be integrated and the OMNeT++ compatible shared library.
into the OMNeT++ build environment.

2. The build environment for the real world application 3.4 Conclusions
has to be reconstructed in the OMNeT++ build envi- The solution using shared libraries includes all advantages of
ronment. This includes compiler and linker flags. the direct source code integration but heavily simplifies the
problems regarding management of both OMNeT++ and
3. External application dependencies have to be integrated real application build environments. The solution based on
into the OMNeT++ build environment. socket connections, is the easiest one but shows synchro-
4. Features like timers and threads that are used in real nization problems that may bias simulation results and ad-
world applications cannot be seamlessly integrated into ditionally, does only work if simulation speed is faster than
OMNeT++. real time. We hence consider the shared library approach
the best choice for the integration of real world applications
into OMNeT++. The rest of the paper will focus on this
Problems (1) to (3) concern the software build environment: integration technique. Section 4 will explain in more de-
Reconstructing the application’s build environment within tail how to integrate real world applications using shared
the OMNeT++ build environment involves integrating all libraries. Section 5 finally focuses on emerging problems
source files and applying all compile and link time switches and gives solutions.
that are needed by the real world application. This can re-
sult in incompatibilities and unstable code: Compile time
switches for character set, exception handling and thread- 4. INTEGRATION STEPS
ing, for example, can result in incompatibilities, break the This section focuses on the integration of real world appli-
build or produce runtime failures. Adding external depen- cations using the shared library approach introduced in sec-
dencies into the OMNeT++ build environment (3) can fur- tion 3.3. Section 4.1 will detail on the required adapta-
ther complicate the build or even make it impossible due to tions on real world application and OMNeT++. The nec-
link time incompatibilities between the external dependen- essary OMNeT++ NED environment will be explained in
cies and OMNeT++. section 4.2.
4.1 Preparing the application
Application Simple module
The first step of preparing the real world application for in-
tegration into OMNeT++ involves creating a simple module Application logic
using the base OMNeT++ class cSimpleModule. The func-
PayloadPacket
tionality of the application’s regular main method has to be
encapsulated into this simple module. The actual code of TcpPacket
the main method will be split into the simple modules con- IpPacket
structor and destructor as well as initialize and finish
Frame
methods. An initialization based on multiple stages can
be implemented using the simple module’s numInitStages Network abstraction and conversion
method.
cMessage
As next steo the network abstraction has to be built. Appli- IPDatagram
cations like intrusion detection systems or network analyzers TCPSegment
parse all protocol layers of a packet. Most often such appli-
cations provide their own parsers to access protocol con-
OMNeT++
tents. These parse the binary network packet and represent
the contents in a structured and easily accessible way. The
intrusion detection systems Bro [11] and Snort [10], for ex- Figure 2: Abstraction layer for OMNeT++/INET
ample, employ such structured protocol parsers. protocol representation and application-specific pro-
tocol representation.
OMNeT++ uses protocol classes that are transmitted within
the simulation model as objects in the simulation process
space. The OMNeT++/INET protocol classes, however,
are different from real binary network data. It is thus not
If the first approach can not be applied the serialization
possible to use the OMNeT++ protocol objects directly for
functions in OMNeT++/INET can be used to serialize the
protocol parsing based on RFC-conform protocol parsers.
protocol objects into a binary Pcap [7] structure (2). This
Figure 1 compares a binary IP packet format which is RFC-
way a Pcap interface can be emulated that provides generic
conform and a binary representation of an IP packet used by
access to all network data including all protocol layers for
OMNeT++/INET. The binary representation for the OM-
the real world application. This approach can e. g. be used
NeT++/INET IP packet was derived from the IPDatagram
when the real world application does not employ protocol
message definition in the IPDatagram.msg file. It can be
parsers but accesses protocol contents through the use of
easily seen that the binary formats are different and that
simple offsets into the binary packet data.
normal protocol parsers can not be used for both formats.
Thus, it is not possible to transparently operate the original
The packet delivery model in the application may differ
protocol parsers of the real world application.
from the event driven approach used in OMNeT++. In an
OMNeT++ simulation packets are delivered through a call-
Integrating a real world application including the applica-
back function, i. e. in a push-based manner. Network ac-
tion’s original parsers is possible by using an abstraction
cess interfaces like Pcap allow pull-based mechanisms to be
layer for the network data. This involves converting the
used instead. If the application uses a pull-based method
OMNeT++-specific protocol objects into structures that are
to access network packets additional buffers must be im-
used inside the application. There exist two different ways
plemented to emulate pull-based network packet access in
to achieve this:
OMNeT++.

Already integrated applications that need to communicate

1. Mapping the OMNeT++/INET protocol objects to with other nodes in the simulation need adaptations, too.
application-internal protocol structures. This is much easier since no protocol parsers or serializ-
ers have to be employed. To enable communication be-
2. Serializing the OMNeT++/INET protocol objects to tween nodes in the simulation an abstraction is needed that
binary format and enable the application to perform allows an application to transparently communicate with
the parsing. other nodes using e. g. sockets under a native environment
and using the OMNeT++/INET facilities when running a
simulation.
Which approach is chosen depends on the fact whether the
application provides inbuilt protocol parsers or not. If the A sound object-oriented design of the real world application
encapsulation of the OMNeT++/INET protocol parsers can makes integration into OMNeT++ rather seamless. The
be mapped to application-internal protocol parsers it is pos- modular architecture allows the exchange of e. g. network
sible to develop a conversion layer that converts the OM- access layers for the OMNeT++ environment. This results
NeT++/INET protocol objects into application-specific pro- in a high level of abstraction and enables the actual appli-
tocol objects (1). The architecture of such an abstraction cation functionality to run independently of the underlying
layer is shown in figure 2. Care must be taken because OM- network access methods. Badly designed applications may
NeT++/INET defines several constants like ICMP type and require more integration efforts but can be integrated into
code values that are not RFC-conform. OMNeT++ nonetheless using the presented method.
 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Version IHL TOS Total length Version IHL

Identification Flags Fragment offset Source IP address
TTL Protocol Header checksum Destination IP address
Source IP address Protocol
Destination IP address TTL Identification (1)
MD
Identification (2) FF
Fragment offset (1)
Fragment offset (2) Diffserv

Figure 1: RFC-conform binary IP format (left) and OMNeT++/INET-based IP format (right)

following entry to the omnetpp.ini file:

Table 1: Flags for shared library building
Type Flag Meaning
[General]
Compiler -fPIC Generate position-independent
...
code (PIC) that is needed for
load-libs="libmyapp"
dynamic linking.
...
Linker -shared Produce a shared object that
can be used to link a shared li-
brary. This instructs OMNeT++ to dynamically load the file
Linker -rdynamic Instructs the linker to add all libmyapp.so at startup. This way the simple module that
symbols to the dynamic symbol was defined in section 4.1 is now available for instantiation.
table. This is needed if the ap- It has to be ensured that the shared library libmyapp.so re-
plication dynamically loads fur- sides in a location where it can be found for dynamic loading.
ther shared libraries which use
functionality from the applica- The NED files that actually use the simple module look as
tion shared library. if the source code was directly embedded, i. e. there is no
Linker -o Specify the output filename difference to the default way of writing NED files.
for the shared library, e. g.
libmyapp.so
5. CHALLENGES
The procedure described in section 4 enables the integrated
application to startup and run within the OMNeT++ sim-
After adapting the source code using the simple module and ulation. Nonetheless only simple applications will run with-
building an appropriate network abstraction the application out problems at this point. Most often problems will emerge
has to be built as a shared library. This applies only to that require special handling. These problems will be ex-
the main executable component. Further shared libraries plained in the next sections and appropriate solutions are
that are used by the application executable do not need presented. The problems and solutions discussed in this sec-
to be changed. Changing the output type from executable tions also partly apply to source code integration (see sec-
to shared library needs adjustment of compiler and linker tion 3.2) and socket connection integration (see section 3.1)
flags. Table 1 gives an overview of useful flags that may technique.
be necessary for compiling and linking a shared library with
the GNU g++ compiler under Linux. Using a build system
like GNU make [12] enables command line flags that can be 5.1 Threads
used to select the runtime environment (e. g. native Linux or Threading is a direct contradiction to the discrete simulation
OMNeT++) and thus easily adapt the compiler and linker approach followed by OMNeT++. A simulation performed
flags. by OMNeT++ is not multi-threaded and thus, implements
no kind of concurrency. In real world applications threads
are commonly used and receive great support by upcom-
ing multicore processors. This results in a huge amount of
4.2 OMNeT++ NED environment software being written based on threads.
After the application has been prepared as shown in sec-
tion 4.1 the OMNeT++ environment has to be built. The In case a multi-threaded application has been integrated as
NED and configuration files for the OMNeT++ simulation previously described one or both of the following problems
are quite similar to the default approach. may occur:

First of all we adapt the omnetpp.ini file. It contains a

[General] section which will be extended to command 1. Application threads don’t receive enough CPU time
OMNeT++ load the application shared library that was from the operating system scheduler and thus don’t
built in section 4.1. In order to achieve this we add the run smoothly.
 2. Access violations occur when a thread tries to access Each of the three features rely on time-based information.
the OMNeT++ simulation environment. Typically, applications, on the one hand, are executed in the
wall clock time domain. An OMNeT++ simulation model,
on the other hand, is executed in its own time domain: the
Threads that only perform little work and then finish are simulation time. Hence, occurrence of any feature within an
often not affected by too little CPU time. Such threads application needs adaptation to run correctly in the simula-
will run correctly and do not need any adaptation in re- tion time domain.
gard to (1). Threads that e. g. wait for processing items
of a queue possibly will run too slow since the OMNeT++ The simulation time can be requested by a simple module
environment consumes all CPU resources. To resolve prob- using the simTime method. This method returns the simula-
lem (1) threads have to be discretized and thus source code tion time as floating point number with double precision in
changes need to be applied. The following example will seconds. Using preprocessor macros the request for the cur-
make this more clear: Consider a thread that waits for items rent time (1) can be easily encapsulated and transparently
in a queue to appear. Then it performs some work on all used by the application:
items until the queue is emptied. Discretizing this thread
can be done by periodically calling a method that processes
all items in the queue. The calling of this method can be #ifdef OMNET_SIMULATION
implemented in the OMNeT++ handleMessage method of #define CUR_TIME (static_cast<unsigned long> \
the application’s simple module. This way the thread itself (cSimpleModule::simTime()* \
is discretized and processing is triggered by OMNeT++ di- 1000.0))
rectly. As processing time in a simple module is not added #else
to the simulation time no time distortion can occur. #define CUR_TIME (static_cast<unsigned long> \
(((double)clock())/ \
Another way to solve the CPU scheduling problem (1) is to ((double)CLOCKS_PER_SEC))*1000.0)
adjust thread priorities. In case of shared library integra- #endif
tion OMNeT++ and all application instances are treated as
a single process. This means that it is not possible in this
This way the application is able to perform time requests
case to adjust process priorities. It is therefore necessary
transparently within an OMNeT++ simulation as well as a
to adjust thread priorities. Adapting thread priorities, how-
normal runtime environment like Linux.
ever, needs deep knowledge of application code and behavior
as well as interaction of threads. The actual thread priority
Sleeping the current thread (2) for a defined amount of time
adaptations have to be performed based on the application
must be done in respect to the simulation time domain.
source code.
As the simulation time is not increasing uniformly, sleep-
ing can not be done using a multiplier in respect to the
The OMNeT++ simulation environment is at any time aware
wall clock time domain. Thus, sleeping mechanisms must
of the currently active code. Therefore a context pointer is
be implemented using OMNeT++ specific features. OM-
used that can be manipulated using the class
NeT++ provides the wait method that simulates speeping
cContextSwitcher. A thread in the real world application
mechanisms using self-messages and can be used by a simple
– which does not necessitate discretization and thus has not
module. Like the request for the current time the sleeping
been discretized – that accesses OMNeT++ functionality,
mechanism can be encapsulated and made compile time-
e. g. through the application’s simple module object, is not
dependent. This results in transparent usage of sleeping
marked as active code because it has not been scheduled by
mechanisms for the application.
OMNeT++ but by its own thread. Therefore, problems oc-
cur that result in access violations (2) because OMNeT++
Timers (3) are implemented in OMNeT++ using self mes-
is not aware of the active code. To circumvent this problem
sages. These are messages that are scheduled with a user
the macros Enter_Method and Enter_Method_Silent can be
defined delay and then sent to the module itself. Periodic
used before accessing simulation objects like the applications
timers can be implemented by rescheduling incoming self
simple module. They use the class cContextSwitcher men-
messages. The self message functionality can be used to im-
tioned before to adjust the context pointer. This way OM-
plement a timer management for the application that can
NeT++ is aware of the currently active code and can handle
handle multiple timers transparently. The timer manage-
message ownership and event scheduling correctly.
ment thus is able to handle multiple timers using different
identifiers in the OMNeT++ self message.
5.2 Timing issues
Applications often depend on time-based information, e. g. 5.3 Shared libraries and symbol space
for the following functionality: As soon as the application’s shared library is dynamically
loaded by OMNeT++ the runtime environment resolves all
1. Requests for the current time. pending symbols. This is performed on a process space-wide
scope. Problems can occur if the application that was loaded
2. Request that the current thread should sleep for a de- using the shared library in turn loads additional shared li-
fined time interval. braries (e. g. plugins). If plugins rely on functionality of the
base application symbol resolution errors can occur. The
3. Use of timers that periodically execute a defined call- reason for this is that when OMNeT++ loads the applica-
back function. tion’s shared library only symbols are mapped into the sym-
 Uses func1,func2

Start OMNeT++/ Load Real world Load Application

OMNeT++ INET Shared-library application Shared-library plugin

Insert e Insert e
Us Us

TCPSegment Func1
UDPPacket Func2
... ...

Process symbol space

Figure 3: Shared library loading by OMNeT++ and by the integrated application.

bol space that are currently needed and thus, unresolved. during runtime, e. g., when the application loads a plugin
Symbols that are not needed at this moment are discarded that depends on func1 or func2.
and not mapped into the symbol space. A plugin that may
get dynamically loaded by the application at a later time The nonexistence of C++ namespaces in OMNeT++ can
may rely on this functionality. Because the functionality has cause further problems that need to be considered. Every
not been mapped into the symbol space at startup loading class in the real world application is compiled into a symbol.
the plugin will fail. This symbol is mapped into the process space and represents
the entry point for the usage of the actual functionality. Two
Figure 3 shows an exemplary scenario where OMNeT++ classes having the same name compete against the symbol
dynamically loads the real world application’s shared library. space entry and will swap one another. This results in the
All symbols that the real world application depends on, e. g. wrong class being instantiated and actually used at runtime.
TCPSegment, are resolved and thus, can be used by the real Function calls on the class will result in the wrong memory
world application. All symbols in the real world application location being executed and fail with access violation errors.
that are currently needed are resolved, too. All symbols that The problem can be resolved by using C++ namespaces in
are currently not needed are not inserted into the symbol the real world application or taking care that no class name
cache. This results in func1 and func2 not being inserted in OMNeT++ and the real world application clash.
into the symbol cache. If the application loads a plugin that
relies on func1 or func2 this functionality – which resides
in the application – is not accessibly by the plugin. 5.4 Process space issues
When deploying several instances of the same application
The solution to this problem is quite easy but requires a on the same machine using e. g. Linux, every instance re-
change in the OMNeT++ code itself. The OMNeT++ code sides in its own process space. Under an OMNeT++ simula-
for loading shared libraries is located in the file loadlib.h tion multiple instantiations of the same application’s simple
at include/platdep/. The method opp_loadlibrary uses module result in the fact that all instances reside in the same
the dlopen method to load shared libraries dynamically at process space. This means that using the real world applica-
runtime. This method call needs to get extended using the tion on several nodes in the simulation network results in all
RTLD_GLOBAL option. Thus, the resulting function call looks application instances sharing the same process space. Every
as follows: static variable or object is thus shared between all instances.
Therefore, special care is needed if static variables and static
dlopen (libfname.c_str(), RTLD_NOW | RTLD_GLOBAL) objects like singletons are used.

The shared process space, however, can also have positive ef-
This causes all symbols in the application shared library to fects on the simulation performance: Shared memory pools,
be mapped into the symbol space when loaded by e. g. by using the Boost Pool Library [3], or the usage of
OMNeT++. This includes symbols that are currently not singleton objects result in smaller overall memory usage and
needed. Thus, symbols that are needed by plugins can be less CPU time consumption. This may speed up simulation
resolved successfully, even at a later point of time. execution.
Based on the changes described above all symbols in our
example that are available in the real world application are 6. CONCLUSIONS
inserted into the symbol cache and available for later usage Integrating real world applications into a simulation environ-
by plugins. This means that func1 and func2 are inserted ment like OMNeT++ enables an evaluation of their behavior
into the symbol cache at the time the shared library of the in large simulated networks. Furthermore, it is possible to
real world application is loaded. Thus, they are available design and evaluate the behavior of distributed real world
 Table 2: Advantages and disadvantages of discussed integration techniques.
Integration technique Advantages Disadvantages
Socket connection Applications like servers and clients can be CPU and timing issues make this integration
integrated without changes to the application technique unstable, inefficient or even impos-
source code. sible to perform.
Source code integration No CPU or time domain issues, thus no bias. Need to reconstruct application build envi-
Straightforward integration method. Easy to ronment with OMNeT++. Applications with
integrate small and simple applications. special compiler and linker settings can not be
integrated due to incompatibilities with OM-
NeT++. Source code adaptations needed.
Shared library integration All advantages of source code integration. Source code adaptations needed.
Avoids problems of build environment and in-
compatibilities.

applications more easily and cost-efficient than in real net- [5] T. Gamer and M. Scharf. Realistic Simulation
works. We presented several techniques that can be used to Environments for IP-based Networks. In Proceedings
integrate existing real world applications into OMNeT++ of the OMNeT++ Workshop, Marseille, France,
and discussed their pros and cons. Focusing on the ap- March 2008.
proach to use shared libraries for integration we presented [6] T. Gamer, M. Scharf, and M. Schöller. Collaborative
detailed instructions how to realize this solution. Addition- Anomaly-based Attack Detection. In Proceedings of
ally, emerging challenges are explained and solutions are IWSOS, pages 280–287. Springer, August 2007.
provided. Table 2 gives a concluding overview of advantages [7] V. Jacobson, C. Leres, and S. McCanne. Tcpdump
and disadvantages of the different integration techniques dis- Pcap. http://www.tcpdump.org, 2000.
cussed in this paper. [8] S. Jansen and A. McGregor. Simulation with real
world network stacks. In Proceedings of the 2005
A well designed network application can be integrated into Winter Simulation Conference, pages 2454–2463,
OMNeT++ more easily than badly structured code. Any- December 2005.
way the integration can be time consuming and complex. It [9] PlanetLab. PlanetLab: An open platform for
would be desirable to have better support by OMNeT++ developing, deploying, and accessing planetary-scale
for the integration of real world applications. Future work services. http://www.planet-lab.org, 2002.
should focus on OMNeT++ extensions that can easily de- [10] M. Roesch. Snort. http://www.snort.org, 2001.
ploy existing real world applications without the need for [11] R. Sommer. Bro: An Open Source Network Intrusion
major adaptations on the application side. Detection System. In Proceedings of the 17.
DFN-Arbeitstagung über Kommunikationsnetze, pages
7. REFERENCES 273–288, June 2003.
[1] I. Baumgart, B. Heep, and S. Krause. OverSim: A [12] R. M. Stallman and R. McGrath. GNU make.
Flexible Overlay Network Simulation Framework. In http://www.gnu.org/software/make, 1988.
Proceedings of 10th IEEE Global Internet Symposium [13] A. Varga. The OMNeT++ Discrete Event Simulation
(GI), pages 79–84, May 2007. System. In Proceedings of the European Simulation
[2] R. Bless and M. Doll. Integration of the FreeBSD Multiconference, pages 319–324, June 2001.
TCP/IP Stack into the discrete event simulator [14] A. Varga. How to extend INET with your own C++
OMNeT++. In Proceedings of the 2004 Winter code. http://www.omnetpp.org, June 2005.
Simulation Conference, pages 1556–1561, December
[15] A. Varga. OMNeT++ Discrete Event Simulation
2004.
System User Manual, 2005. Version 3.2.
[3] S. Cleary. Boost Pool Library.
[16] W. Willinger, M. S. Taqqu, R. Sherman, and D. V.
http://www.boost.org/libs/pool, 2000.
Wilson. Self-similarity through high-variability:
[4] D. Dittrich. The ”Tribe Flood Network” distributed statistical analysis of ethernet LAN traffic at the
denial of service attack tool. source level. In Proceedings of ACM SIGCOMM,
http://staff.washington.edu/dittrich/misc/tfn.analysis, pages 100–113, February 1995.
October 1999.