[Ns-developers] Summer of Code nsc/ns-3 integration status, week 06
fw at strlen.de
Mon Jun 2 08:29:42 PDT 2008
as explained in my last mail, the ns-3-nsc basics work.
To allow run time usage of available nsc stacks, i've extended the
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.
A simulation can now e.g.:
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.
All network stacks shipping with nsc-0.3.0 work with the tcp-large-transfer
example, i've uploaded a few trace files to http://www.strlen.de/cradle/ .
Note that the Linux and lwip stacks need two minor bug fixes to work
properly, I've sent those to Sam for consideration. I've updated the
wiki page and started to document some of the ns-3nsc plumbing details,
I'll try to keep it up to date.
- nsc-ipv4-l3-protocol.cc. This is exactly the same as
ipv4-l3-protocol.cc, the only difference is that the nsc version
doesn't remove the ip header before forwarding the packet to layer 4.
I'll see about reconstructing the ipv4 header in the nsc-tcp-l4 class
instead, this would make nsc-ipv4-l3-protocol obsolete.
- code cleanup, there are still code redundancies in the nsc-socket and
nsc-tcp-l4 classes. Will work on this.
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
I also plan to do some more tests with mixed setups (i.e.
nsc-Linux <-> nsc-FreeBSD, etc.)
More information about the Ns-developers