[Ns-developers] ns-3 and future development

[Tom Henderson]

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 
clarified.

> 
> 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, 
> context));

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?

http://sourceforge.net/docs/E02/en/#top

Admittedly, this is harder than a local box.

Regards,
Tom