Changes between Version 20 and Version 21 of Tutorials/a0Basic/Tutorial2


Ignore:
Timestamp:
Nov 28, 2007, 11:49:19 PM (16 years ago)
Author:
thierry
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Tutorials/a0Basic/Tutorial2

    v20 v21  
    3030#     Nodes in this group will execute the application 'test:proto:sender'
    3131#
    32 defNodes('sender', [1,1]) {|node|
     32defGroup('sender', [1,1]) {|node|
    3333
    3434  node.prototype("test:proto:sender", {
    … …  
    4646#     Nodes in this group will execute the application 'test:proto:receiver'
    4747#
    48 defNodes('receiver', [1,2]) {|node|
     48defGroup('receiver', [1,2]) {|node|
    4949
    5050  node.prototype("test:proto:receiver" , {
    … …  
    5959#     this experiment
    6060#
    61 allNodes.net.w0 { |w|
     61allGroups.net.w0 { |w|
    6262  w.type = 'b'
    6363  w.essid = "helloworld"
    … …  
    7373  wait 30
    7474
    75   allNodes.startApplications
     75  allGroups.startApplications
    7676  wait 40
    7777
    … …  
    8585As you noticed the "Hello World" script is almost ''human-readable'', and is quite understandable to any computer-literate reader. As already mentioned above, deep Ruby knowledge is '''not''' a prerequisite to running experiment on the ORBIT testbed.
    8686
    87  * The first part of this script uses the ORBIT method ''defNodes'' to define a group of nodes called ''sender'', which contains a unique node ''[1,1]''. Next, we perform some specific configurations on the node(s) within the group ''sender''. These specific configurations are described in a ''block'' (e.g. curly braces) that directly follows the ''defNodes'' call. Within this ''block'', we first assign a particular application to the ''sender'' node(s). This application is a traffic generator and is accessed via a ''prototype'' which is called ''test:proto:sender'' in this example. A prototype can be viewed as a wrapper around an existing application. It defines some set of properties (i.e. "parameters"), which allows us to customize the wrapped application for the specific need of an experiment. For example in this case, through the prototype we can set the address of the sender, and various parameters of the traffic generator itself, such as packet size, rate, and the protocol over which to send the traffic. Prototypes are normally defined in separate files, and the ORBIT platform has a set of predefined prototypes for some basic applications. For example, the prototype "test:proto:sender" is a wrapper around the application "otg" (orbit traffic generator). Other tutorials (see [wiki:Tutorial main page]) describes how to write your own prototypes for your own or existing applications. The last line on this 'sender' block configures the first wireless interface ''w0'' on the node(s) in this block into ''managed'' mode.
     87 * The first part of this script uses the ORBIT method ''defGroup'' to define a group of nodes called ''sender'', which contains a unique node ''[1,1]''. Next, we perform some specific configurations on the node(s) within the group ''sender''. These specific configurations are described in a ''block'' (e.g. curly braces) that directly follows the ''defGroup'' call. Within this ''block'', we first assign a particular application to the ''sender'' node(s). This application is a traffic generator and is accessed via a ''prototype'' which is called ''test:proto:sender'' in this example. A prototype can be viewed as a wrapper around an existing application. It defines some set of properties (i.e. "parameters"), which allows us to customize the wrapped application for the specific need of an experiment. For example in this case, through the prototype we can set the address of the sender, and various parameters of the traffic generator itself, such as packet size, rate, and the protocol over which to send the traffic. Prototypes are normally defined in separate files, and the ORBIT platform has a set of predefined prototypes for some basic applications. For example, the prototype "test:proto:sender" is a wrapper around the application "otg" (orbit traffic generator). Other tutorials (see [wiki:Tutorial main page]) describes how to write your own prototypes for your own or existing applications. The last line on this 'sender' block configures the first wireless interface ''w0'' on the node(s) in this block into ''managed'' mode.
    8888
    8989{{{
    … …  
    9191# A)  Define the 'sender' group, which has the unique node [1,1]
    9292#
    93 defNodes('sender', [1,1]) {|node|       
     93defGroup('sender', [1,1]) {|node|       
    9494           
    9595  # Assign the prototype "test:proto:sender" to the node(s) in this group
    … …  
    109109}}}
    110110
    111  * The second part of the script is very similar to the previous one. Here we define a 'receiver' group with a unique node, this time node [1,2]. Again we define some specific configuration for the 'receiver' nodes in a block following the ''defNodes'' call. In this case, we assign a traffic sink application to the node(s) via a prototype called "test:proto:receiver", we also set the 'protocol' property of this prototype. Finally, we configure the "w0" wireless interface of the node(s) into "master" mode.
     111 * The second part of the script is very similar to the previous one. Here we define a 'receiver' group with a unique node, this time node [1,2]. Again we define some specific configuration for the 'receiver' nodes in a block following the ''defGroup'' call. In this case, we assign a traffic sink application to the node(s) via a prototype called "test:proto:receiver", we also set the 'protocol' property of this prototype. Finally, we configure the "w0" wireless interface of the node(s) into "master" mode.
    112112
    113113{{{
    … …  
    115115# B)  Define the 'receiver' group, which has the unique node [1,2]
    116116#
    117 defNodes('receiver', [1,2]) {|node|
     117defGroup('receiver', [1,2]) {|node|
    118118
    119119  # Assign the prototype "test:proto:receiver" to the node(s) in this group
    … …  
    128128
    129129
    130  * The third part of the script presents an example on how to configure interfaces on all nodes in one place to ensure consistency. The command ''allNodes.net.w0'' describes the first wireless interface on all nodes in the experiment. The code inside the following ''block'' (e.g. curly braces) configures various parameters of these interfaces. In this specific example, we configure the interface as an 802.11b type, set the ''essid'' to a common string, and set it's IP address. We obviously do not want to set all the interfaces to the same IP address, thus any string beginning with a '%' is ''personalized'' for each node by replacing characters prefixed by a '%' with a local string. In this specific example, '%y' is replaced by the 'y' coordinate of the node. For this specific experiment setup, the IP address of node [1,1] will be 192.168.1.1, while node [1,2] will have 192.168.1.2 assigned. This part concludes the configuration phase of the experiment.
     130 * The third part of the script presents an example on how to configure interfaces on all nodes in one place to ensure consistency. The command ''allGroups.net.w0'' describes the first wireless interface on all nodes in the experiment. The code inside the following ''block'' (e.g. curly braces) configures various parameters of these interfaces. In this specific example, we configure the interface as an 802.11b type, set the ''essid'' to a common string, and set it's IP address. We obviously do not want to set all the interfaces to the same IP address, thus any string beginning with a '%' is ''personalized'' for each node by replacing characters prefixed by a '%' with a local string. In this specific example, '%y' is replaced by the 'y' coordinate of the node. For this specific experiment setup, the IP address of node [1,1] will be 192.168.1.1, while node [1,2] will have 192.168.1.2 assigned. This part concludes the configuration phase of the experiment.
    131131
    132132{{{
    … …  
    134134# C)  Configure the wireless interfaces of All the Nodes in this experiment
    135135#
    136 allNodes.net.w0 { |w|
     136allGroups.net.w0 { |w|
    137137  w.type = 'b'
    138138  w.essid = "helloworld"
    … …  
    141141}}}
    142142
    143  * This final part of the script describes the operation to execute in order to perform the experiment. An ORBIT experiment script basically defines a state machine, or more precisely, what sequence of commands should be executed if the experiments enters a particular state. The only state we will use in this experiment is ''whenAllInstalled''. This state is reached when all the nodes are configures and all the requested applications are installed and ready to go. The sequence of commands to perform are given in a ''block'' following the ''whenAllInstalled'' call. The first command 'wait 30' will suspend the execution for 30 seconds to ensure that indeed everything has settled. The ''allNodes.startApplications'' will then send a command to all nodes to start the applications assigned to them (via the use of ''prototypes'') in the previous script parts. Thus in this example, this command will start a traffic generator on node [1,1] and a corresponding sink on node [1,2]. The different parameters for these applications are taken from the above definition as well. Finally, the next line 'wait 40' will suspend the control of the experiment for 40 seconds (during which the applications on the nodes '''will run''' and exchange traffic), before concluding the experiment with a call to ''Experiment.done''.
     143 * This final part of the script describes the operation to execute in order to perform the experiment. An ORBIT experiment script basically defines a state machine, or more precisely, what sequence of commands should be executed if the experiments enters a particular state. The only state we will use in this experiment is ''whenAllInstalled''. This state is reached when all the nodes are configures and all the requested applications are installed and ready to go. The sequence of commands to perform are given in a ''block'' following the ''whenAllInstalled'' call. The first command 'wait 30' will suspend the execution for 30 seconds to ensure that indeed everything has settled. The ''allGroups.startApplications'' will then send a command to all nodes to start the applications assigned to them (via the use of ''prototypes'') in the previous script parts. Thus in this example, this command will start a traffic generator on node [1,1] and a corresponding sink on node [1,2]. The different parameters for these applications are taken from the above definition as well. Finally, the next line 'wait 40' will suspend the control of the experiment for 40 seconds (during which the applications on the nodes '''will run''' and exchange traffic), before concluding the experiment with a call to ''Experiment.done''.
    144144
    145145{{{
    … …  
    154154
    155155  # Start all the Applications on all the nodes
    156   allNodes.startApplications
     156  allGroups.startApplications
    157157
    158158  # Wait for 40sec
    … …  
    202202 }}}
    203203
    204  * Install a disk image which includes ''nodeAgent4'' on the nodes of this testbed. For example, you can use the latest ''baseline.ndz'' disk image. This disk image installation is done using the ''orbit load'' command above, and detailed instructions on how to execute it on the nodes on a testbed can be found [wiki:Tutorial/HowToImage here].
     204 * Install a disk image which includes ''nodeAgent4'' on the nodes of this testbed. For example, you can use the latest ''baseline.ndz'' disk image. This disk image installation is done using the ''orbit load'' command above. Detailed instructions on how to perform such disk image installation on the nodes on a testbed can be found [wiki:Tutorial/HowToImage here].
    205205
    206206