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

[Liu Jian]

Mathieu,


>> 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 ?
>
it should be everything when something changes, e.g. user want to add an 
interface address, it send an piece of netlink message to kernel which contains
all necessary informantion, if kernel finish the operation successfully, 
it send the address message back, which may contains even more attributes.
	

>
>>     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.
>
	that were great hints for the quagga porting:)
	but you may misunderstood what i were concerned about, i tried to get some idea
	about how libnl/quagga be used by ns3? what useful issue ns3 can get from
	the realworld applications? 
>> 	 
>> 	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 ?).
	
	it use setsockopt to set sendbuff/recvbuff size. 

	Liu Jian