I see that ns-3 has been started this month:

http://www.isi.edu/nsnam/ns-3/ns-3-cri-workshop-2006.pdf

I'm a fan of C++ and have spent many years earning my income coding C++.
I'm also a big fan of Unix based systems and use Ubuntu as my platform for
research. But I think that the C++/TCL combination that makes up NS-2 is
not the right language for writing network simulations.

I'd like to make the suggestion that NS-3 be coded in Java 1.6, and not
C++ for the following reasons:

1.) Java is a memory-managed language: This means that programmers can
spend their time writing simulations, not tracking down memory leaks and
array out of bound errors.

2.) Java is heavily used in educational environments: This is where NS-3
is likely to be used.

3.) Java 1.6 supports an open scripting interface: The 1.6 JDK supports
JavaScript and several other scripting languages. TCL is not popular right
now, forcing most users of NS-2 to spend their time leaning TCL rather
than writing simulations. Using Java 1.6 would prevent lock-in to an
unpopular scripting language.

4.) Java supports multiple platforms: Unfortunately not everyone uses UNIX
based OS’s. So NS-2 users who don’t have a UNIX based system are forced to
get one, or use Cygwin or a virtual machine. With Java, users could do
development on any platform that supports Java 1.6.

5.) Java has strong typing: Rather than casting an Event into a class and
hoping it is the right one, you can use 'instanceof' to figure out what
type of class it is. Stronger typing helps during debugging and moves the
catching of more errors to the compile stage. Again, letting the developer
spend more time simulating and less time coding.

6.) Java has better debug logging: Through the use of a standardized
interface, users can adjust how much debug information is logged, and
where it is logged, and they can do it by class and package level. You can
even list the file and line number of each debug statement through custom
formatting. This is better than the all on or off compile directives.
Sorting through only the debug info you want saves time.

7.) Easier crash debugging: Stack traces are easier to debug than seg
faults and core dumps.

8.) Standardized documentation format for API: Javadocs pulled from the
source code are a great way to document code.

9.) Common API: Java has a great set of common libraries that are part of
the language. This significantly simplifies programming by not forcing the
developer to create their own implementations of hash maps, decimal
programming, string formatting, etc. And since everyone uses the same
library, the code is more consistent and easier to understand.

10.) Threading support: Java has excellent support for multi-threaded
applications. It includes many built in functions for synchronization, and
they aren’t OS specific.

11.) Standardized testing framework: JUnit is an excellent framework for
unit tests. NS-2 makes excellent use of unit tests, and JUnit can extend
that support in a standardized way for better IDE and build script
support.

12.) Java is fast: Java's internal tuning can make it run faster than a
poorly tuned C++ program. Since the emphasis is on running simulations
accurately and not in spending time to make them run faster, this
auto-tuning is ideal.

13.) Java has great libraries that would allow output to be directly put
into Excel spreadsheets or databases.

14.) Java code is easier to build in different environments. Developers
often get tripped up on getting NS-2 running on different platforms. The
all-in-one build was a great step forward, but this process could be
greatly simplified with Java.

15.) Java supports 64-bit operation: Moving between 32 bit and 64 bit
machines is easier with Java than C++.

I spent several months using NS-2 to create the protocol I needed for my
dissertation research. I really like a large number of things about NS-2,
but I came to the conclusion I was spending too much of my time playing
with NS-2 and not enough of my time doing research. As I had to implement
all 7 layers for my protocol, I decided to switch to Java. I tried to
architect my program as close as possible to NS-2. I use the same event
passing, the same scheduler interface, and I also have interactive
front-end scripting.

I have found in the last few weeks that I've worked on it that I have
progressed much faster in my research.

If you’d like to see what I’ve done so far, here are the javadocs:
http://www.cravenfamily.com/javadoc/

And the code:
http://www.cravenfamily.com/jns.tar.gz

Paul Vincent Craven
[EMAIL PROTECTED]
http://www.cravenfamily.com

Reply via email to