Understanding the NS framework

From nsnam
Revision as of 08:19, 28 November 2008 by Lachlan (Talk | contribs) (Link to NS manual)

Jump to: navigation, search

Once you've gone over the NS-2 manual and learned how to create basic scripts, you might need to understand how the NS-2 internals work. Here are some tips on how to get started.

Reading the code

  • ns-allinone-2.31\ns-2.31\tcl\lib\ns-lib.tcl: The central Tcl class in NS-2 is the 'Simulator' class. When hacking NS-2, this is probably the best class to get started with.
  • Event: This class is defined in scheduler.h, and there isn't much to it. But it is a critical class as the messages that passes are instances of this class. Each event has a Handler class which processes it. This Handler class is subclassed by the appropriate layer/protocol/trace functionality.
  • Packet: Defined in packet.h, this is your basic packet. Learning how to cast and decipher the header is an important task for learning NS-2 hacking.
  • Handler: Also defined in scheduler.h, this is the interface for handling an event. If you want to 'hook' into NS-2 and handle events, you'll subclass this and implement the handle function.

Tracing the code

From here, tracing through some normal program flow is a good idea. You can do this with puts and printf statements. Tracing through with a debugger works well also. If you like graphical debuggers, Eclipse works will on Linux with the CDT Tools bridgat. I would recommend the following breakpoints:

  • BaseTrace::dump: This is where data is dumped to your trace log. You might want to modify this to dump to the console as well. By putting a break point here, you can examine the call stack to see how we got to be logging this.
  • Scheduler::schedule: NS-2 works by passing a lot of messages. Not just a message from node a to node b, but the message is passed from the app layer, to the routing layer, to the link layer to the mac layer to the physical layer. Messages are also passed to the tracing class for tracing. Messages are passed directly, or by scheduling them to be passed later. By putting a breakpoint on the scheduler, you will see what messages are being scheduled. You may wish to log the UID so you can track when a message is scheduled, and when it is dispatched.
  • Scheduler::dispatch: Once you've scheduled it, you'll want to see where it goes.