This section talks about the discrete event schedulers of NS. As described in the Overview section, the main users of an event scheduler are network components that simulate packet-handling delay or that need timers. Figure 5 shows each network object using an event scheduler. Note that a network object that issues an event is the one who handles the event later at scheduled time. Also note that the data path between network objects is different from the event path. Actually, packets are handed from one network object to another using send(Packet* p) {target_->recv(p)}; method of the sender and recv(Packet*, Handler* h = 0) method of the receiver.
Figure 5. Discrete Event Scheduler
NS has two different types of event schedulers implemented. These are real-time and non-real-time schedulers. For a non-real-time scheduler, three implementations (List, Heap and Calendar) are available, even though they are all logically perform the same. This is because of backward compatibility: some early implementation of network components added by a user (not the original ones included in a package) may use a specific type of scheduler not through public functions but hacking around the internals. The Calendar non-real-time scheduler is set as the default. The real-time scheduler is for emulation, which allow the simulator to interact with a real network. Currently, emulation is under development although an experimental version is available. The following is an example of selecting a specific event scheduler:
. . . set ns [new Simulator] $ns use-scheduler Heap . . . |
Another use of an event scheduler is to schedule simulation events, such as when to start an FTP application, when to finish a simulation, or for simulation scenario generation prior to a simulation run. An event scheduler object itself has simulation scheduling member functions such as at time "string" that issue a special event called AtEvent at a specified simulation time. An "AtEvent" is actually a child class of "Event", which has an additional variable to hold the given string. However, it is treated the same as a normal (packet related) event within the event scheduler. When a simulation is started, and as the scheduled time for an AtEvent in the event queue comes, the AtEvent is passed to an "AtEvent handler" that is created once and handles all AtEvents, and the OTcl command specified by the string field of the AtEvent is executed. The following is a simulation event scheduling line added version of the above example.
. . . set ns [new Simulator] $ns use-scheduler Heap $ns at 300.5 "complete_sim" . . . proc complete_sim {} { . . . } |
You might noticed from the above example that at time "string" is a member function of the Simulator object (set ns [new Simulator]). But remember that the Simulator object just acts as a user interface, and it actually calls the member functions of network objects or a scheduler object that does the real job. Followings are a partial list and brief description of Simulator object member functions that interface with scheduler member functions:
Simulator instproc now | # return scheduler's notion of current time | |
Simulator instproc at args | # schedule execution of code at specified time | |
Simulator instproc at-now args | # schedule execution of code at now | |
Simulator instproc after n args | # schedule execution of code after n secs | |
Simulator instproc run args | # start scheduler | |
Simulator instproc halt | # stop (pause) scheduler |