When we talk about NS emulation, there are two types of emulation:
Fig1. Experiments, Events & NSE
Introduction to Event System
Emulab event system is implemented as a thin layer on top of the 'elvin' system. Elvin is a publish/subscribe system, meaning that programs that want to receive events connect to the elvin server and subscribe to all events for a particular node, for a particular traffic generator, etc.
An event scheduler is run for each experiment. It's this scheduler's job to keep track of future events for the experiment, and send them at the appropriate time. The most basic example of this are events specified through the NS file, but interactive event via tevc commands can also be used to schedule events for some future time. eventsys_control can be used to control the scheduler, stopping it, starting it, or replaying all events listed in the NS file.
The event system is also used to communicate information about the state of nodes (not clear how?). At several times during the node boot process, nodes contact tmcd informing it of their current state. State changes are also inferred from some external event, such as a node DHCPing, or running 'power' to power cycle a stuck node. All of these state changes are received by a daemon on boss, 'stated'. In addition to receiving state transition events, stated can generate them for nodes that cannot do so themselves - for example, it can ping nodes that are running OSes that do not report in, to detect when they come up. Stated reads state machines from the database, and can detect nodes that timeout in specific states (i.e., they begin to boot, but then hang), or that somehow make invalid state transitions. During experiment swapin, when all nodes have reached the ISUP state, a 'time start' event is sent so that all agents will have a similar idea of when the experiment began (sync server described in Section 8 is an alternative approach that Emulab is using.).
On the nodes, the main things that interact with the event system are delay nodes, traffic generators, and the program agents. Delay nodes subscribe to events for their link, so that the delay can be changed, the link brought down, etc. Traffic generators can be turned on and off, and have their parameters changed through this method. And, if the user specified any 'Program' objects in the NS file, agents are
started so that they can be dynamically started and stopped.
The parsed ns file yields information about the topology and sequence of events required for the experiment. This information is stored in the db. The event scheduler in Boss gets all the event information from the db and supplies it one at a time to elvind. Elvind on BOSS communicates with the agent on the node when an event involving that node is scheduled. This communication is entirely over the control network. Elvind instructs the agent at the node to supply that event to the traffic generator or the NS emulator agent (e.g., NSE ftp and telnet agents) running on the node. (need to know the detail of communications between elvind and agents and between elvind and scheduler?) Currently, the NSE in the test node only supports very limited events such as Traffic generation. It is still unknown whether the sophisticated operation could be done (e.g., change link characteristics).
How NS objects communicate over network
To realize nse, nse must be made in each node with "nse make" command. For example, there is a Ftp/tcp agent implementation in the ns-2 source package. Also, the system has its own BSD socket system which is also supporting TCP. So, what's the relationship between them.
Zhibin Wu, 04/22/2004 09:15:59 PM