[Ns-developers] Summer of Code nsc/ns-3 integration status, week 06

[Florian Westphal]

Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> On Mon, 2008-06-02 at 17:29 +0200, Florian Westphal wrote:
> > To allow run time usage of available nsc stacks, i've extended the
> > InternetStackHelper:
> > SetTcpType(std::string) allows to specify an nsc stack to use.
> > I also added a second Install() method that gets a Node
> > as the argument.
> 
> You do not need to do the latter because NodeContainer has a constructor
> which takes a Ptr<Node> so, the following should work as-is:

You're right, so i've backed out that part of the change.

> > A simulation can now e.g.:
> > 
> >    InternetStackHelper internet;
> >    internet.SetTcpType("Linux");
> >    internet.Install (c);
> > 
> > To tell ns-3 that NSCs Linux stack should be used.
> > The InternetStackHelper maps the Name to the corresponding shared
> > library. I'm not satisfied with this; I think that maybe it should
> > get the actual shared library in the first place, because eventually
> > there will probably a lot of "Linux" stacks, e.g. linux2618.so,
> > linux2625.so, and so on. In any case, this is a minor detail and this
> > can be adjusted as needed later on. In case SetTcpType() isn't called,
> > the ns-3 tcp stack is used.
> 
> I see. That API is a bit confusing them because SetTcpType does more
> than set the type of TCP implementation to use: it selects the "nsc" TCP
> implementation, and within nsc, it selects an nsc stack using the nsc
> dlopen mechanisms. So, I would expect something like this instead:
> 
> void InternetStackHelper::SetTcpDefault (void)
> void InternetStackHelper::SetNscTcp (std::string subtype);

Fair enough, i've changed it accordingly.

> There is another, more fancy and flexible, option which would, however,
> be more complex to implement.
[Explanation snipped]

Ok, i recon this would be the better solution. I'll read the
WifiHelper::SetRemoteStationManager implementation you mentioned.

> > Other open issues are the ns-3-nsc API, e.g. how should sysctls (e.g.
> > for disabling SACK in Linux) and nsc setsockopts be exposed to the user?
> > I will think about this and try to come forward with a few ideas this
> > week. 
> 
> What would totally rock would be to allow sysctl to be exported as
> Attributes which would allow us to control sysctl with normal
> attributes, and, GtkConfigStore among others.

This sounds great, so i'll definitely plan to look into this.

Thanks for your feedback,
Florian