[Ns-developers] gsoc wrapup

[Tom Henderson]

Florian Westphal wrote:
> Tom Henderson <tomh at tomh.org> wrote:
>> Florian Westphal wrote:
>>> Here is everything in a single patch:
>>> http://www.strlen.de/cradle/ns-3-nsc-aug-22-2008.diff
>> Florian, here are a few issues that will need to be dealt with during or 
>> shortly after the merge:
>>
>> - the code regarding add_default_gateway() is not clean and should be added 
>> to the tracker as a bug when the merge occurs, if not fixed before then
> 
> No disagreement here, but I'm not sure what the _right_ solution is.
> Any ideas?

I think this might be solvable in two steps:
1) keep the existing limitation on single-interface operation in nsc, 
but improve the code that calls to add_default_gateway() by having it 
call a method in Ipv4.
2) remove the limitation on single-interface operation in nsc by having 
it do some kind of prerouting call to the Ipv4 object.

Some of this (esp. 2) is not supported presently on the ns-3 side of 
things so I think it needs to be considered also as part of the ipv4 
improvement project.

I will look at it some more next week.

> 
>> - we need to figure out how to control, in general, the handling of 
>> compilation options in our unit tests and regression suite (I already 
>> mentioned this), and we need a unit test or regression test added.  For 
>> instance, since the available nsc stacks are platform-dependent, I wonder 
>> what we will check in regression tests (a known-good stack that works in 
>> all environments, only?)
> 
> nsc doesn't change the behaviour of the ns-3 example files.
> What do you want me to do?

I mean, there are some stacks that require older gcc versions-- do we 
just want to test only ones that require a commonly available gcc 
version?  i.e. do not put a regression test in for an NSC stack that is 
not likely to be supportable by most users.

> As for the nsc stacks, the main problem is that the Linux stacks
> that work on both x86 and x86_64 generate different pcap traces
> depending on the host architecture (for instance, it will pick different TCP
> source ports on x86 vs. _64).
> 
>> - some doxygen is missing (e.g., InternetStackHelper::SetTcpDefault())
> 
> See my reply to Raj, i think that method should go.
> I'll walk through things again and will try to add missing docs for any
> methods i have added.
> 
>> - it would help to have a chapter in the manual and some words in the 
>> tutorial about NSC.  The "README.nsc" should migrate somewhere else.
> 
> Where exactly should README.nsc go? Should it move to the wiki instead?
> I could try to move contents from the ns-3-nsc wiki page to the manual,
> if that is deemed acceptable. 

If you are interested in maintaining a wiki page on it, I would suggest 
that.  Maybe move the contents of README.nsc into a new "Section 1" on 
the wiki page.

I think it would be nice, longer-term, to have a manual chapter on NSC 
that goes into some detail of what is going on and how to use it, but 
the contents of README.nsc and troubleshooting/porting hints for NSC 
(such as already on your wiki page), future plans, development schedule, 
etc. are good for the wiki, IMO.

Tom