 |
|
The Tulip application allows the execution of commands described in an XML format scenario. The scenario is executed according to a XML configuration file. The commands are dynamically loaded from dll plugins locatred in /lib installation directory. There are two kinds of plugins:
- General: commands which can be accessed by any scenario file, like for instance arithmetic functions. The corresponding plugin files have the “tl” prefix.
tlCommon.dll: functions related to logic, mathematics. tlCrypto.dll: cryptographic functions. tlSystem.dll: system dependent functions. tlTime.dll: time metering functions. tlUtils.dll: Tulip elements management commands (test, remote control, agent management).
- Protocol: commands related to the chosen mode in the configuration. Tulip implements the concept of object overload: if a command is implemented in a general library as well as the protocol library, the protocol implementation will be used. Typically, the message send and receive functions in the chosen mode are generally implemented in protocol libraries.= The name of a protocol library is simply the mode name (ex, MEGACO.dll).
Tulip allows the sequential execution of these commands, or in parallel across several traffic agents. As described in the chart, each XMC source scenario is verified according to the application DTD (data structure description), then compiled into a “.tlp” file. This file will then be loaded/executed by the application core.
Tulip includes the following modules:
- Compiler: takes as input a XML scenario, DTD files and a configuration file. It then performs syntax checks and compiles the file into a proprietary format. The output is a file with .tlp extension, which can be used by application core. Therefore, compilation can be performed outside of execution, like a c++ application.
- Tulip CORE: application core, which initialize the other modules, parses the configuration file and load compiled test sheets. It also controls the agents described below.
- Agent: module executed on a separate thread, which starts by the execution of a root scenario, which may launch other scenarii afterwards. Each agent has its own separate variable space, only global variables are shared.
- Internal router: specific module which routes the packets received from test pipeline to the correct agent, or responder.
- Scheduler: when Tulip is used for traffic purpose, this module activates an agent every intersimulation period in order to achieve the specified rate (ex CAPS).
|
| Generalities |
|
 |
