[Ns-developers] [GSOC:quagga-porting] status reports

[Mathieu Lacage]

On Wed, 2008-07-23 at 23:41 +0800, Liu Jian wrote:
> Mathieu, Tom,  
> >
> >On Sun, 2008-07-20 at 10:43 -0700, Tom Henderson wrote:
> >
> >> Given that we are aiming for mergeable code by the end of this
> project, 
> >> I think we should discuss what the merge steps might be.  It
> depends on 
> >> ns-3-simu branch, so should that repo be going in as a first step?
> >
> >Ideally, we should be able to merge the netlink code in ns-3-dev
> before
> >ns-3-simu. This means that we will not merge libnl but I viewed libnl
> >porting more as a serious testing effort of the netlink code than
> >anything else.
> >
> >Then, the goal would be to extend and add what is needed to ns-3-simu
> to
> >complete an initial quagga port. 
> >
> >So, to summarize, the ideal outcome of this project at the end of the
> >gsoc timeline is:
> >  - merging netlink sockets in ns-3-dev with good testing
> 	
> 	i have just pushed some new testing code at
> src/node/netlink-socket-test.cc, will you give some comments?
> 	
> >  - merging simu extensions in ns-3-simu
> 	
> 	do you mean i merge the simu_xxx to ns-3-simu and merge the netlink
> socket to ns-3-dev? 
> 	As two separate parts?     

as two separate parts, yes.
	
> >So, a possible schedule for the next weeks would be:
> >  1) this week: identify the needs of the broadcast netlink messages,
> >implement them
> 	i have read the quagga code, it use the broadcast netlink as this
> way: 	
> 	quaaga creat two netlink sockets: one (multicast group zero)is for
> user sending cmd to kernel, 
> 	the other is for user monitoring the kernel's changes(multicast group
> nozero).
> 	an example: user send a cmd "adding address" to kernel-> kernel
> handle it, add address infromation
> 	inside the kernel enviroment, and send an update inforamtion to
> netlink group RTM_GRP_IPV4ADDR ->
> 	the second socket recv this address-changed information and update
> its own information table in quagga enviroment.

Does the second socket receive only the changed parts or does it receive
everything everytime something changes ?

> 	
> 	so just follow the line,  use an container to store the created
> multicast netlink sockets, when add/del 
> 	operation happened inside, NetlinkSocket send the information to the
> dest-group sockets.

That sounds like a good plan.

> 	
> >  2) next week: merge netlink code in ns-3-dev
> 	
> 	as you know my repo based on ns-3-simu, should i merge the whole?
> 	or anthor way: check out the ns-3-dev, only add netlink files to it,
> missing the src/porting files?

The second way.

> 	
> >  3) focus on trying to get an initial quagga port.
> >
> >3) is likely to be impossible to achieve within the bounds of the
> >current gsoc timeline but getting a very minimal running prototype
> would
> >be a great start.
> 	
> 	i am also afraid i would not finish my gsoc project as i was applying
> oringally, but if i can contribute some code
> 	to ns3, that would be my best pleasure.
> 	
>     about the quagga porting, the goal i think is to supply some APIs
> or class for ns3 user using, but now i miss the direction,
> 	from the experience of libnl porting, the goal is likely to be making
> it run on top of ns3, how ns3 user can use the libnl's 
> 	existed convenient APIs, that is make libnl to be used by ns3. 
> 	
> 	i was planning porting quaage following the libnl's step, make it run
> successfully on top of ns-3-simu. the same question:

Agreed.

>     quaaga has some useful apis and user cmds,how to let them used by
> ns3? if we just make real world application run on top of ns3 but 
> 	not getting its useless, then why do we porting it? just some doubts,
> not clear about it:)

In the real world, the way you control quagga is through a configuration
file or command-line arguments. For the command-line arguments, it is
easy within ns-3-simu to provide new command-line arguments in
ProcessManager::Create.

For the configuration file, it is also pretty easy: ns-3-simu provides
simu_open and simu_close to open and close files so, if you make quagga
use these functions instead of open and close, you will be able to use a
per-node configuration file under the files-[nodeid]/ directory. For
example, if your application is running on node 2 and calls simu_open
("/etc/quagga.conf"), this will try to open the file
files-2/etc/quagga.conf.

> 	 
> 	and about simu_xxx functions,  there were many more functions need to
> support for quagga, which I list at the first beginning in my wiki.

yes.

> 	when porting libnl, there were still two: setsockopt() and
> getsockname() not implemented in ProcessManager(need your help).

I think that the only way to support getsockname would be to add a
GetSockName method to the Socket base class: you need to propose a patch
to craig to add this method to src/node/socket.h and implement it in
subclasses. setsockopt should be supported with attributes so, you just
need to implement an attribute which matches the socket option set by
the user (what socket option is set by libnl ?).

Mathieu

Mathieu