[Ns-developers] ns-3 and future development
tomh at tomh.org
Mon Jan 16 22:08:59 PST 2006
mathieu lacage wrote:
> hi tom,
> Tom Henderson wrote:
>> and available under GPL. There are three main reasons for considering
>> using pieces of gtnets:
>> - gtnets has already worked out the parallelization issues
> I think there are 3 issues to solve for parallelization:
> 1) a core time synchronization library and message exchange library
> 2) make the simulator use the core synchronization library
> 3) deployment of simulation scenarios over a parallel system (a
> cluster or an smp system) in a way which is transparent to the user and
> which does not require any changes to purely serialized scenarios.
> As I understand it, gtnets solves 2). 1) is solved by the rtikit
> library. 3) is not solved in gtnets. Unless I am grossly mistaken, the
> license of rtikit is _not_ compatible with the gpl. More generally, it
> does not seem to be distributed freely: you have to ask for it by email
> (which I did but never got any reply so, I have never been able to get
> access to its source code). This means that we will probably need to
> re-implement a functional clone of rtikit, whichever core is used as a
> basis for a future simulator.
I did not realize that RTIKIT had this restriction-- will try to get it
> The way gtnets solves 2) is interesting because it is known to work: I
> have tried to design the yans simulation APIs such that following the
> ideas put forward by gtnets is really easy.
> Finally, I think 3) is critical to make parallel simulations usable. I
> plan to work on a prototype of a solution of this problem. It would
> involve the use of python and its native xml-rpc mechanism to perform
> deployment. I could outline a more detailed technical proposal in a
> later email if there is interest in it.
This would be nice, I agree.
>> - gtnets is further along
> I think you mean: "gtnets has more working/useful models". Am I right ?
Yes-- that and maybe they have corrected some missteps along the way.
>> Also, could be a stack/ directory to contain ipv4, ipv6, posix, and
>> other more researchy stacks that might be devised in the future. This
>> would also perhaps match better with Sam Jansen's network simulation
>> cradle work.
> I am reluctant here but I have trouble explaining why. I think it is
> related to the fact that I fail to see what kind of API each "stack"
> should implement. i.e., I do not see any equivalent of the "network
> interface" API for "stacks".
I don't know if there will be such a well known API-- that may be the
point. Although I tend to think that sockets or some other middleware
layer API will generally persist.
>> 2. Core
>> One might consider making the API from this core accessible via some
>> single header file (e.g., "core.h"), which could include all of the
>> simulator/ .h files.
> please, please, no. Large-scale developement projects need to focus on
> minimizing dependencies between the various modules.
OK, your point is well taken.
>> Timer classes are missing.
> Is the following not simple enough ?
> Simulation::insert_at_s (10.0, make_event (&MyClass::timeout, my_class,
Ability to schedule, reschedule, cancel, and inquire about the status of
the timer. Might require the above method returning a handle to the
event, and some "status_" flag in the event that can be used to
deactivate it without having to traverse the data structure to find the
event-- this stuff has been worked out before in other simulators.
>> I would not rely on assembly code at this stage (under
>> fiber-context-x86-linux-gcc.c). I think that consideration
>> has to be given to more than small set of Linux/x86 distributions--
>> the ns user base demands this.
> I welcome suggestions on how to do what this file does without assembly
> :) Some unix systems provide the make_context posix function which could
> be used but it is not present on osx for example. A lot of other unixes
> do not offer it either so, I don't have any solution to offer.
> If the question is "can we have similar assembly code for other widely
> used platforms ?", the answer is: if you ask for it, you will get it if
> you give me access to such a platform. I have access to x86-64-linux-gcc
> so, I will probably do it whenever there is a request for it.
> ppc-osx-gcc will be harder since no one around has an apple box (I will
> be happy with ssh access).
Have you looked at the sourceforge compile farm, where you can get shell
access as a sourceforge user?
Admittedly, this is harder than a local box.
More information about the Ns-developers