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

[Mathieu Lacage]

hi florian,

[we discussed the content of that mail extensively on irc, but here is a
small summary for those who are interested] Sorry for this (very very)
late reply.

On Mon, 2008-06-09 at 18:04 +0200, Florian Westphal wrote:

> The two major outstanding integration problems that I'm aware of are now
> sysctl and setsockopt support.
> 
> I already talked to Mathieu about this (thanks again!), but let me first
> illustrate how NSC currently exposes sysctls.
> 
> In NSC, a stack may implement the INetStack method
> virtual int sysctl(const char *sysctl_name, void *oldval, size_t
> 		    *oldlenp, void *newval, size_t newlen)
> 
> (which matches FreeBSDs sysctlbyname(3)). In ns-3-nsc, the INetStack
> methods can be called from the NscTcpL4Protocol class.
> 
> And here the fun begins: sysctl() is non-portable, in all aspects.
> For example, nsc's Linux 2.6.18 stack glue has to do some (really basic)
> sysctl_name parsing to build the (integer) vector that is expected by
> the Linux kernels do_sysctl() function.
> Also, the sysctl_name itself is stack specific, e.g. Linux might have
> a 'net.ipv4.tcp_sack' sysctl that you can set to 0 or 1 to
> enable/disable TCP SACK support. FreeBSD has 'net.inet.tcp.sack.enable',
> and so on.
> 
> So while something like
> .AddAttribute ("net.ipv4.tcp_sack", "enable/disable Linux TCP SACK support",
> IntegerValue(1),MakeIntegerAccessor(&NscTcpL4Protocol::SysctlGetLinuxNetIpv4Tcp_sack,
> 		 &NscTcpL4Protocol::SysctlSetLinuxNetIpv4Tcp_sack),
> 
> might look great at a first glance, I don't think this will work out in
> practice. We'd have to add dozens of those attributes (and methods) for Linux alone,
> and we'd have to add many more for every single stack in nsc.

Yes, I think that the above is a loser: it would be pointless to have to
maintain all these attributes by hand.


> 
> Bottom line: I'd like to just hand string/value pairs to NSC without
> looking at the content, it will be enough work to handle those in the
> nsc stack glue code...

Florian is currently trying to make this work by adding code to NSC to
allow a dynamic iteration of the tree-like structure of sysctl values
and by dynamically creating an ns-3 object hierarchy on top of it.



> Maybe we can talk about this on irc after tomorrows ns-3 irc meeting.
> I'd also be interested in hearing about opinions on what I should work
> next. Personally I think it would be best to first add getpeername
> to nsc (to add the SocketRxAddressTag),
> but perhaps I've missed something more obvious/beneficial.

Looks like you have already done the above.

regards,
Mathieu