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

Liu Jian liujatp at gmail.com
Wed Jul 23 08:41:18 PDT 2008


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?     	

	
>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.
	
	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.
	
>  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?
	
>  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:
    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:)
	 
	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.
	when porting libnl, there were still two: setsockopt() and getsockname() not implemented in ProcessManager(need your help).
	

 Liu Jian






More information about the Ns-developers mailing list