NS, an event scheduler keeps track of simulation time and fires all the
events in the event queue scheduled for the current time by invoking
appropriate network components, which usually are the ones who issued the
events, and let them do the appropriate action associated with packet
pointed by the event. Network components communicate with one another
passing packets, however this does not consume actual simulation time.
All the network components that need to spend some simulation time
handling a packet (i.e. need a delay) use the event scheduler by issuing
an event for the packet and waiting for the event to be fired to itself
before doing further action handling the packet. For example, a network
switch component that simulates a switch with 20 microseconds of switching
delay issues an event for a packet to be switched to the scheduler as an
event 20 microsecond later. The scheduler after 20 microsecond dequeues
the event and fires it to the switch component, which then passes the
packet to an appropriate output link component. Another use of an event
scheduler is timer. For example, TCP needs a timer to keep track of a packet
transmission time out for retransmission (transmission of a packet with
the same TCP packet number but different NS packet ID). Timers use event
schedulers in a similar manner that delay does. The only difference is
that timer measures a time value associated with a packet and does an
appropriate action related to that packet after a certain time goes by,
and does not simulate a delay.
NS is written not only in OTcl but in C++ also. For efficiency reason,
NS separates the data path implementation from control path
implementations. In order to reduce packet and event processing time (not
simulation time), the event scheduler and the basic network component
objects in the data path are written and compiled using C++. These compiled
objects are made available to the OTcl interpreter through an OTcl linkage
that creates a matching OTcl object for each of the C++ objects and makes
the control functions and the configurable variables specified by the C++
object act as member functions and member variables of the corresponding
OTcl object. In this way, the controls of the C++ objects are given to
OTcl. It is also possible to add member functions and variables to a C++
linked OTcl object. The objects in C++ that do not need to be controlled
in a simulation or internally used by another object do not need to be
linked to OTcl. Likewise, an object (not in the data path) can be entirely
implemented in OTcl. Figure 2 shows an object hierarchy example in C++
and OTcl. One thing to note in the figure is that for C++ objects that
have an OTcl linkage forming a hierarchy, there is a matching OTcl object
hierarchy very similar to that of C++.