This is an old revision of the document!
Wireless Explorer doar câteva nivele .
Citim tutoriale și rulăm exemple. Text de J. Chung și M. Claypool reprodus de pe NS by example
NS (version 2) is an object-oriented, discrete event driven network simulator developed at UC Berkely written in C++ and OTcl. NS is primarily useful for simulating local and wide area networks. Although NS is fairly easy to use once you get to know the simulator, it is quite difficult for a first time user, because there are few user-friendly manuals. Even though there is a lot of documentation written by the developers which has in depth explanation of the simulator, it is written with the depth of a skilled NS user. The purpose of this project is to give a new user some basic idea of how the simultor works, how to setup simulation networks, where to look for further information about network components in simulator codes, how to create new network components, etc., mainly by giving simple examples and brief explanations based on our experiences. Although all the usage of the simulator or possible network simulation setups may not be covered in this project, the project should help a new user to get started quickly.
As mentioned in the overview section, NS is basically an OTcl interpreter with network simulation object libraries. It is very useful to know how to program in OTcl to use NS. This section shows an example Tcl and OTcl script, from which one can get the basic idea of programming in OTcl. These examples are from the 5th VINT/NS Simulation Tutorial/Workshop. This section and the sections after assumes that the reader installed NS, and is familiar with C and C++.
Example 1 is a general Tcl script that shows how to create a procedure and call it, how to assign values to variables, and how to make a loop. Knowing that OTcl is Object-orieneted extension of Tcl, it is obvious that all Tcl commands work on OTcl - the relationship between Tcl and Otcl is just same as C and C++. To run this script you should download ex-tcl.tcl, and type “ns ex-tcl.tcl” at your shell prompt - the command “ns” starts the NS (an OTcl interpreter). You will also get the same results if you type “tcl ex-tcl.tcl”, if tcl8.0 is installed in your machine.
# Writing a procedure called "test" proc test {} { set a 43 set b 27 set c [expr $a + $b] set d [expr [expr $a - $b] * $c] for {set k 0} {$k < 10} {incr k} { if {$k < 5} { puts "k < 5, pow = [expr pow($d, $k)]" } else { puts "k >= 5, mod = [expr $d % $k]" } } } # Calling the "test" procedure created above test
In Tcl, the keyword proc is used to define a procedure, followed by an procedure name and arguments in curly brackets. The keyword set is used to assign a value to a variable. [expr …] is to make the interpreter calculate the value of expression within the bracket after the keyword. One thing to note is that to get the value assigned to a variable, ns color 1 Blue
ns node]
set n1 [
ns node]
set n3 [
ns duplex-link $n0 $n2 2Mb 10ms DropTail
$ns duplex-link $n1
ns duplex-link $n2 $n3 1.7Mb 20ms DropTail
#Set Queue Size of link (n2-n3) to 5
$ns queue-limit $n2 ns duplex-link-op $n0 $n2 orient right-down
$ns duplex-link-op $n1
ns duplex-link-op $n2 $n3 orient right
#Monitor the queue for link n2-n3 (for NAM)
$ns duplex-link-op $n2 tcp set class_ 2
$ns attach-agent $n0
ns attach-agent $n3 $sinkt
$ns connect $tcp
tcp set fid_ 1
#Setup a FTP over TCP connection
set ftp [new Application/FTP]
$ftp attach-agent $tcp
ns attach-agent $n1 $udp
set usink [new Agent/LossMonitor]
$ns attach-agent $n3
ns connect $udp $usink
cbr attach-agent
cbr set type_ CBR
cbr set rate_ 1mb
ns namtrace-all
ns flush-trace
#Close the NAM trace file close $nf #Execute NAM on the trace file exec nam out.nam & exit 0
}
#Schedule events for the CBR and FTP agents $ns at 0.1 "$cbr start” $ns at 1.0 "$ftp start” $ns at 14.0 "$ftp stop” $ns at 14.5 "$cbr stop”
#Call the finish procedure after 15 seconds of simulation time
cbr set packet_size_]”
puts “CBR interval = [
ns run
</file>
The following is the explanation of the script above. In general, an NS script starts with making a Simulator object instance.
set ns [new Simulator]
generates an NS simulator object instance, and assigns it to variable ns (italics is used for variables and values in this section). What this line does is the following:The “Simulator” object has member functions that do the following:
Most of member functions are for simulation setup (referred to as plumbing functions in the Overview section) and scheduling, however some of them are for the NAM display. The “Simulator” object member function implementations are located in the “ns-2/tcl/lib/ns-lib.tcl” file.
$ns color fid color
is to set color of the packets for a flow specified by the flow id (fid). This member function of “Simulator” object is for the NAM display, and has no effect on the actual simulation. $ns namtrace-all file-descriptor
This member function tells the simulator to record simulation traces in NAM input format. It also gives the file name that the trace will be written to later by the command set n0 [$ns node]
The member function node creates a node. A node in NS is compound object made of address and port classifiers (described in a later section). Users can create a node by separately creating an address and a port classifier objects and connecting them together. However, this member function of Simulator object makes the job easier. To see how a node is created, look at the files: “ns-2/tcl/libs/ns-lib.tcl” and “ns-2/tcl/libs/ns-node.tcl”.$ns duplex-link node1 node2 bandwidth delay queue-type
creates two simplex links of specified bandwidth and delay, and connects the two specified nodes. In NS, the output queue of a node is implemented as a part of a link, therefore users should specify the queue-type when creating links. In the above simulation script, DropTail queue is used. If the reader wants to use a RED queue, simply replace the word DropTail with RED. The NS implementation of a link is shown in a later section. Like a node, a link is a compound object, and users can create its sub-objects and connect them and the nodes. Link source codes can be found in “ns-2/tcl/libs/ns-lib.tcl” and “ns-2/tcl/libs/ns-link.tcl” files. One thing to note is that you can insert error modules in a link component to simulate a lossy link (actually users can make and insert any network objects). Refer to the NS documentation to find out how to do this.$ns queue-limit node1 node2 number
This line sets the queue limit of the two simplex links that connect node1 and node2 to the number specified. At this point, the authors do not know how many of these kinds of member functions of Simulator objects are available and what they are. Please take a look at “ns-2/tcl/libs/ns-lib.tcl” and “ns-2/tcl/libs/ns-link.tcl”, or NS documentation for more information.$ns duplex-link-op node1 node2 …
The next couple of lines are used for the NAM display. To see the effects of these lines, users can comment these lines out and try the simulation.Now that the basic network setup is done, the next thing to do is to setup traffic agents such as TCP and UDP, traffic sources such as FTP and CBR, and attach them to nodes and agents respectively.
set tcp [new Agent/TCP]
This line shows how to create a TCP agent. But in general, users can create any agent or traffic sources in this way. Agents and traffic sources are in fact basic objects (not compound objects), mostly implemented in C++ and linked to OTcl. Therefore, there are no specific Simulator object member functions that create these object instances. To create agents or traffic sources, a user should know the class names these objects (Agent/TCP, Agnet/TCPSink, Application/FTP and so on). This information can be found in the NS documentation or partly in this documentation. But one shortcut is to look at the “ns-2/tcl/libs/ns-default.tcl” file. This file contains the default configurable parameter value settings for available network objects. Therefore, it works as a good indicator of what kind of network objects are available in NS and what are the configurable parameters.$ns attach-agent node agent
The attach-agent member function attaches an agent object created to a node object. Actually, what this function does is call the attach member function of specified node, which attaches the given agent to itself. Therefore, a user can do the same thing by, for example, $n0 attach $tcp. Similarly, each agent object has a member function attach-agent that attaches a traffic source object to itself.$ns connect agent1 agent2
After two agents that will communicate with each other are created, the next thing is to establish a logical network connection between them. This line establishes a network connection by setting the destination address to each others' network and port address pair.Assuming that all the network configuration is done, the next thing to do is write a simulation scenario (i.e. simulation scheduling). The Simulator object has many scheduling member functions. However, the one that is mostly used is the following:
$ns at time “string”
This member function of a Simulator object makes the scheduler (scheduler_ is the variable that points the scheduler object created by [new Scheduler] command at the beginning of the script) to schedule the execution of the specified string at given simulation time. For example, $ns at 0.1 "$cbr start” will make the scheduler call a start member function of the CBR traffic source object, which starts the CBR to transmit data. In NS, usually a traffic source does not transmit actual data, but it notifies the underlying agent that it has some amount of data to transmit, and the agent, just knowing how much of the data to transfer, creates packets and sends them.
After all network configuration, scheduling and post-simulation procedure specifications are done, the only thing left is to run the simulation. This is done by $ns run.
ns ./ns-simple.tcl
, se execută scriptul care generează “filmul simulării” out.name, și se lansează animatorul nam
. Rulați slide-ul în animator pentru a accelera filmul, observați transferul pachetelor și comportarea cozii din nodul 2
ns2 permite implementarea cu ușurință a procedurilor specializate de generare de loguri. Aceste proceduri sunt apelate periodic în timpul simulării și permit adresarea tuturor datelor specifice nodurilor, fluxurilor, cozilor, și ale celorlalte entități din rețea.
În partea de final a scriptului de mai sus, inserați codul următor. Apelată periodic, această procedură contorizează numărul de octe ți primiți de destinația UDP, și numărul de octeți confirmați la sursa TCP. În acest mod, se poate calcula debitul obținut de cele două fluxuri pe intervale fixe de timp. Cele două valori sunt stocate periodic într-un fișier text out.tr
.
#Open a trace file set fout [open out.tr w] #save running byte counters set tbytes 0 set ubytes 0 proc record {} { global tcp usink fout ubytes tbytes set ns [Simulator instance] #Set the time after which the procedure should be called again set time 0.25 #How many bytes have been received/acked? set tbytes1 [expr [$tcp set ack_]*[$tcp set packetSize_]] set ubytes1 [expr [$usink set bytes_]] set now [$ns now] #Calculate the bandwidth (in MBit/s) and write it to the log puts $fout "$now [expr ($tbytes1 - $tbytes)/$time*8/1000000] \ [expr ($ubytes1 - $ubytes)/$time*8/1000000]" #Reset the bytes_ values on the traffic sinks set tbytes $tbytes1 set ubytes $ubytes1 #Re-schedule the procedure $ns at [expr $now+$time] "record" }
Procedura finish
trebuie actualizată pentru a include închiderea fișierului de trace, și pentru a plota conținutul său:
#Close the trace file close $fout #Call gnuplot to display the results exec echo "plot 'out.tr' using 1:2 t 'TCP' w l, '' using 1:3 t 'UDP' w l" | gnuplot -persist
În plus, înainte de a demara simularea, trebuie să armăm procedura record cu $ns at 0.0 “record”
.
După execuția scriptului, se vor lansa automat atât fereastra animatorului, cât și o fereastră gnuplot care afișează conținutul fișierului trace out.tr
out.nam
și out.tr