close
Warning:
BrowserModule failed with ConfigurationError: Look in the Trac log for more information.
- Timestamp:
-
Aug 15, 2008, 4:40:42 PM (16 years ago)
- Author:
-
heep
- Comment:
-
--
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v11
|
v12
|
|
49 | 49 | The module declaration is divided in two subsections: parameters and gates. The parameters subsection contains custom parameters established by the user, while the gates subsection establishes the connections to the other layers: from_udp and to_udp to the UDP layer, and from_app and to_app to the application layer. The direct_in gate is used for e.g. internal RPCs. |
50 | 50 | |
51 | | Modules can be nested inside one another. Modules without any inner modules are called simple modules, and are declared using the keyword simple. Only simple modules can have its behaviour customized with C++ (see Section 4). On the other hand, modules with inner nested modules are called compound modules, and act only as containers; they are declared with the keyword module. |
| 51 | Modules can be nested inside one another. Modules without any inner modules are called simple modules, and are declared using the keyword simple. Only simple modules can have its behaviour customized with C++ (see Section 3). On the other hand, modules with inner nested modules are called compound modules, and act only as containers; they are declared with the keyword module. |
52 | 52 | |
53 | 53 | An example compound module is as follows: |
… |
… |
|
72 | 72 | == 2.2 Setting parameters == |
73 | 73 | |
74 | | The user can set custom values for module parameters in the file omnetpp.ini, or in default.ini for general default values, both located in the Simulation folder (see Section 5). Parameters are hierarchic, separated by dots for each layer. For example, setting a parameter for a specific overlay module in a node can be done as follows: |
| 74 | The user can set custom values for module parameters in the file omnetpp.ini, or in default.ini for general default values, both located in the Simulation folder (see Section 4). Parameters are hierarchic, separated by dots for each layer. For example, setting a parameter for a specific overlay module in a node can be done as follows: |
75 | 75 | {{{ |
76 | 76 | SimpleOverlay.overlayTerminal[5].overlay.myParam1 = 1024 |
… |
… |
|
368 | 368 | Each simulation environment class is defined as a run. A configuration file can contain different amounts of runs, each with a different number. We need to set up the network in that run. There are two base networks: SimpleUnderlay and Ipv4Underlay. !SimpleUnderlay is a simplified flat network where each node is assigned coordinates, packet latencies are calculated based on the distance of the source and destination node coordinates, and each nodes are directly connected to one another. Ipv4Underlay emulates real-life networks and contain hierarchies of nodes, routers, and backbones. The network type is set with the first-tier parameter network. Network modules can be accessed under the names of !SimpleNetwork for !SimpleUnderlay and Ipv4Network for Ipv4Underlay. The module in charge of building the network is called underlayConfigurator. |
369 | 369 | |
370 | | Now, once the network type has been set, now we need to declare the node classes. We can declare each node to be made of the same components and attributes, or create different classes each with its own attributes. Each class is represented by a churnGenerator. For example, we can create a network with one type of node (see also Section 2.2): |
| 370 | Now, once the network type has been set, now we need to declare the node classes. We can declare each node to be made of the same components and attributes, or create different classes each with its own attributes. Each class is represented by a churnGenerator. For example, we can create a network with one type of node: |
371 | 371 | |
372 | 372 | {{{ |
… |
… |
|
413 | 413 | Now run {{{ ./makemake }}} and {{{ make }}} in the root folder. That should compile your new modules. |
414 | 414 | |
415 | | In order to run it, you need to setup your simulation run in omnetpp.ini as explained in Section 5. Make sure that you selected default values for all parameters in default.ini, or you'll be prompted for a value when the simulation begins - for each instance of the parameter. To start !OverSim, enter the directory Simulations and run : |
| 415 | In order to run it, you need to setup your simulation run in omnetpp.ini as explained in Section 4. Make sure that you selected default values for all parameters in default.ini, or you'll be prompted for a value when the simulation begins - for each instance of the parameter. To start !OverSim, enter the directory Simulations and run : |
416 | 416 | {{{ |
417 | 417 | ../bin/OverSim [-f customConfigFile] [-r runNumber] |