Changes between Version 32 and Version 33 of OverSimDevelop

Timestamp:

Sep 11, 2009, 10:42:15 AM (15 years ago)

Author:

Ingmar Baumgart

Comment:

--

OverSimDevelop

@@ -10 +10 @@
 
 == '''Be careful:''' ==
-   * This documentation covers only OMNeT++-4.0 compatible versions of OverSim! [[BR]]
-     (For documentation about OMNeT++-3.x compatible versions of OverSim, see OverSimDevelopOld)
+   * This documentation covers only OMNeT++-4.0 compatible versions of !OverSim! [[BR]]
+     (For documentation about OMNeT++-3.x compatible versions of !OverSim, see OverSimDevelopOld)
    * It is still under development and may be partly incorrect or outdated! [[BR]]
      '''--> Any suggestions or contributions would be appreciated! '''
@@ -58 +58 @@
 The parameters subsection is a list of module properties. These parameters must be set before the simulation (or the simulator will stop and ask you for a value each time a module is created!) and will be read-only while the simulation is running. As parameter types we can use booleans (bool), strings, integers, or doubles; custom types (either module declarations or C++ types) can also be used.
 
-Notice that, since we're writing an overlay module, we'll declare our module as inheriting from the parent class BaseOverlay. Therefore we'll use "extends BaseOverlay" in the module definition. Since we want to use our own code for our module, we'll add "@class(!MyOverlay)" in the parameters section, to tell the simulator that !MyOverlay is a class of its own.
-
-Now, we'll declare our application module in a similar way. Application files should be located in !OverSim/src/applications, so we'll create a folder called myapplication (folder names are in lower case by convention) and there a file called !MyApplication.ned.
+Notice that, since we're writing an overlay module, we'll declare our module as inheriting from the parent class BaseOverlay. Therefore we'll use {{{extends BaseOverlay}}} in the module definition. Since we want to use our own code for our module, we'll add "@class(!MyOverlay)" in the parameters section, to tell the simulator that !MyOverlay is a class of its own.
+
+Now, we'll declare our application module in a similar way. Application files should be located in {{{OverSim/src/applications}}}, so we'll create a folder called myapplication (folder names are in lower case by convention) and there a file called !MyApplication.ned.
 
 {{{
@@ -196 +196 @@
 In this section, we'll implement our overlay and application. But first, let's do a introduction about some of the important variable types used in !OverSim.
 
-* [http://www.oversim.org/chrome/site/doc/neddoc/oversim.common.BaseOverlay.html BaseOverlay]: Template overlay module class. All overlay modules should derive from it.[[BR]]
-* [http://www.oversim.org/chrome/site/doc/neddoc/oversim.common.BaseOverlay.html BaseApp]: Template application module class. All application modules should derive from it.[[BR]]
-* [http://www.oversim.org/chrome/site/doc/doxy/classOverlayKey.html OverlayKey]: Class to describe overlay keys. Internally it stores the key as an bit array. [[BR]]
+* BaseOverlay: Template overlay module class. All overlay modules should derive from it.[[BR]]
+* BaseApp: Template application module class. All application modules should derive from it.[[BR]]
+* OverlayKey: Class to describe overlay keys. Internally it stores the key as an bit array. [[BR]]
                     Its value can be set in different ways when it's being initialized:[[BR]]
 {{{
@@ -211 +211 @@
 
 * IPvXAddress:        Generic IP address, can contain either an IPv4 address (IPAddress) or an IPv6 address (IPv6Address).[[BR]]
-* [http://www.oversim.org/chrome/site/doc/doxy/classTransportAddress.html TransportAddress]:   A structure containing bot an IPvXAddress (field "ip"), and a port (field "port").[[BR]]
-* [http://www.oversim.org/chrome/site/doc/doxy/classNodeHandle.html NodeHandle]:         A child class of TransportAddress, additionaly contains an OverlayKey (field "key"). In overlay and application modules, the variable "thisNode" contains the NodeHandle value representing the host. However, in application modules the "key" field may not be set.[[BR]]
+* TransportAddress:   A structure containing bot an IPvXAddress (field "ip"), and a port (field "port").[[BR]]
+* NodeHandle:         A child class of TransportAddress, additionaly contains an OverlayKey (field "key"). In overlay and application modules, the variable {{{thisNode}}} contains the NodeHandle value representing the host. However, in application modules the {{{key}}} field may not be set.[[BR]]
 
 Now, let's continue with the implementation.
@@ -555 +555 @@
 }}}
 
-In this example, we are working with the network "SimpleUnderlayNetwork". From there, we retrieve the overlayTerminal array, get index 5, and then its overlay module. For that module, we'll use the submodule myOverlay, and set the parameter enableDrops to true.
+In this example, we are working with the network SimpleUnderlayNetwork. From there, we retrieve the overlayTerminal array, get index 5, and then its overlay module. For that module, we'll use the submodule myOverlay, and set the parameter enableDrops to true.
 
 This case, however, is too specific. We may not always work with the SimpleUnderlayNetwork. Or we may need that parameter to be set for all nodes. For those cases the wildcards * and ** are of use. For example:
@@ -569 +569 @@
 Should a module parameter not be set in either configuration file, or match any wildcard, !OverSim will prompt the user to enter a value for each instance of the module. For simulations with a big amount of nodes, setting each parameter individually quickly becomes overwhelming. Therefore, it is recommended that every module parameter be assigned a default value in default.ini.
 
-Notice that these are parameter paths, not to be confused with module paths from NED declarations (see Section 2.1). In this case, the parameter paths describe a set of modules and submodules to follow to reach the inner parameter we want. On the other hand, the module paths describe the folder under !OverSim/src/ in which the declaration of the NED module will be found.
+Notice that these are parameter paths, not to be confused with module paths from NED declarations (see Section 2.1). In this case, the parameter paths describe a set of modules and submodules to follow to reach the inner parameter we want. On the other hand, the module paths describe the folder under {{{!OverSim/src/}}} in which the declaration of the NED module will be found.
 
 == 5.2 Creating our Configuration File ==
@@ -599 +599 @@
 Now, unless specified otherwise, all configurations will use SimpleUnderlayNetwork as their network. Notice that the value of "network" is a module path, which represents the location of the ned file, and not a parameter path.
 
-Further on networks, there are two base networks: SimpleUnderlayNetwork and InetUnderlayNetwork. !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. Network modules can be accessed under the names of SimpleUnderlayNetwork for !SimpleUnderlay and InetUnderlayNetwork for !InetUnderlay. 
+Further on networks, there are two base networks: SimpleUnderlayNetwork and InetUnderlayNetwork. !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. !InetUnderlay emulates real-life networks and contain hierarchies of nodes, routers, and backbones. Network modules can be accessed under the names of SimpleUnderlayNetwork for !SimpleUnderlay and InetUnderlayNetwork for !InetUnderlay. 
 
 Now, once the network type has been set, we can set the parameter values that we'll need. For example, let's create a configuration called "Example". There are two basic parts that should be configured: the churn type, and the node parameters.