Ns Direction
From Nsnam
A new project has been formed for ns-3 development: see ns-3 wiki page
This page is used for discussion of the direction of the ns project.
Contents |
ns and scripting
Currently ns-2 uses OTcl as its scripting language. Two problems have been raised:
- Largely unmaintained, unknown language.
- Use alongside C++ in current code base is haphazard. Some models are implemented partly in OTcl, calling between C++ and OTcl.
Make the core models of ns-3 entirely C++. Allow writing simulations in C++ if desired. Have a wrapper that allows using a scripting language over the top. The C++ core has no knowledge of the scripting language being used.
- Could use a program such as SWIG to generate wrapper code for the scripting language. Possibly with some code to clean up the interface.
- Choice of scripting language is under discussion. Possibilities:
- XOTcl, incr Tcl - keep with the Tcl theme, change to a widely used Tcl distribution
- Python, Perl, Ruby - common interpreted languages used today. No pros or cons raised yet.
- Scheme/Lisp - not well understood by many, and one goal is simplicity of writing simulations.
- Java - easy to build on top of C++, well known by many. Otherwise is compiled, doesn't add a lot when C++ is already available?
ns as a library
All the talk of ns (core) being only in C++ suggests that ns will be a library/shared object. This would be the easiest way of having it, as dynamic loading of "simulation instructions" (for lack of a better term) is far more difficult and error prone and subject to difficult to resolve versioning issues. Libraries have there own versioning system
Using ns as a library makes adding different scripting languages relatively easy, they are a C++ programs that use the ns core library. --LeeBegg 05:39, 15 December 2005 (PST)
Useful ns-developers posts
Here are a few useful posts to the ns-developers mailing list.
More as they come. --LeeBegg 05:18, 15 June 2006 (PDT)
Issues about ns2
There are a number of issues and shortcomings in ns2 that we have a chance to correct in ns3. I would like to encourage everyone to add to the list below. A few where sent to me by private email, others I thought of in my work with ns2. Please add more, work will go into fixing these issues. --LeeBegg 04:25, 26 June 2006 (PDT)
- Difficult to add extension
- Difficult to add new higher layers
- Hard to debug
- Mixture of C++ and OTcl
- Lack of source documentation
- Lack of architecture documentation
- No packet encapsulation
- Network layers not cleanly separated
- Little known scripting language
- No pcap output
- Hard to replace core parts to provide different behaviour (emulation/distributed/parallel)
Please add any other points (except for notes about missing models of protocols) above.
Craven: My thoughts:
- Classifiers, I really don't like the current setup. All the bit shifting is non-intuitive.
- I would like having a strongly typed language for this type of application
- The debug output is inconsistant and difficult to parse, particularly when you have both wired and wireless
- Having to manually free the memory
- Improved abstration so a wider range of apps and protocols can be supported and stacked
- Better debug logging and control over what logging is turned on or off
- Too much of the 'core' programming is in TCL, making it harder to trace
I really like a lot of the architecture of NS2, but I found myself spending too much time 'messing' with NS2 and not enough time simulating. Since my simulation involves having to do the full OSI stack myself, I recently gave up and started trying to implement NS2 in java. With the new java 1.6 that is out, you can do scripting as well. I have been quite pleased with the results. The stronger typing in java really helps with managing all the different types of events. Pcraven 12:21, 2 July 2006 (PDT)
