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

[Liu Jian]

hi all,

As methieu suggested, i give an detailed intruction about my project.
code location: http://code.nsnam.org/lj/quagga-porting/

1, netlink socket.(files at: src/node/netlink-xxx.h/cc)

it is a subclass of Socket, and has the uniform send/recv socket APIs.

the point is how to serilize/desirilize an netlink message. the netlink message is not as simple as an 
IP header, but it has an alterable payload message body due to different message type. So i take the 
whole message(header and payloads) as an Header, all different payload has its own seri/deseri api 
partly followed the Header class(netlink-message.h/cc and netlink-messge-route.h/cc).

another point is to simulate how the linux kernel handle the netlink messages. The kernel is very 
complicated, i just simple implement it. 

the line how the message passed is:
user socket send an request to kenerl, the kernel netlink socket recv it and handle it, then send ack back 
to user-space socket. where in my NetlinkSocket, there no kernel socket exist. when NetlinkSocket call 
send() to transfer an message, Socket handle it directly as kernel, then send the ack/message back to 
its own recv-queue.

this simplied implementation can support the message exchange between userspace and kernel process when 
sockaddr_nl's group value is 0, which called the unicast message, and it was not supportable for 
broadcast when this group value is nozoro.  when broadcasting message, kernel should send the 
ack/response message to the sockets which were in the defined group, but now there no mechanism to 
manage and classify the sockets. so the broadcast was NULL. but the NetlinkSocket unicast is OK for 
simply use.

About the Netlink protocol, i were just focusing at NETLINK_ROUTE, and for quagga use, just aim at three 
class of message(interface address, interface info, route enrty) with operations(add/delete/get).
After learing how the kernel code handle the message, i use the ipv4 APIs to implemented them. Because  
the ns3 is an simulte tool, it has not so much inforamtion as the real kernel. an example: route entry. 
ns3 IPv4route entry only has dest and interface members but netlink route has more than 10 attributes, 
so NetlinkSocket was an simple simulation based on the NS3 ipv4 contents.
(the example code at netlink-socket-test.cc) 

2, libnl port
libnl is an library using netlink socket, it provide user many brief programs to manage and operate 
route inforamtion and others. mathieu suggest me to port it and make it run on top of ns-3-simu, being 
aim at testing my NetlinkMessage seri/deseri , learing how the real-world netlink socket be used and 
improving NetlinkSocket.

Because libnl is an real-world application, i use the src/process simu module to do with it, which has 
the posix APIs and definetions.
files at : src/porting
the steps:
1, define some macros to replace the real world definitions with SIMU_XXXX(at src/porting/porting-
types.h) 
2, replace the real world head files"#include<system-headfiles>" with simu head files 
"#include<simu_headfiles>". 
3, replace the system call xxx() with simu_xxx() in libnl source files. 

For the three steps, i added some simu_xxx() and SIMU_XXX the libnl used in process module , because the 
process module were also on working by mathieu and many were unsupportable.

libnl programs locate at src/porting/libnl/src/*.c, there were all real-world application. 
ns-3-simu/process module provide mechanism to run programs on top of ns3, so, for porting, where i 
create an program "libnl-test" (src/porting/libnl-test.cc) to run libnl at an better defined ns3 Node.

As for nl-addr-dump program, change the name int main(int, char*[]) to nl_addr_dump(int, char*[]), then 
ns3 node can run it as an process.
just like ns3 programs, it run as:
./waf --shell;
cd build/debug/src/porting
./libnl nl-addr-dump xml
then it dump the current node's interface address inforamtion through NS3 NetlinkSocket.

now i have tested 8 programs:nl_addr_dump, nl_link_dump, nl_route_dump, nl_addr_add, nl_addr_delete; 
nl_route_add, nl_route_delete, nl_route_get. they all run normally.

so, i am not sure if this can be claimed to a milestone success, for the NetlinkSocket is still not 
strong enough though is can be simply used. 

i am planning to step foward to quagga porting, but one problem is the broadcast way the netlink used, 
which is also used by quagga, currently, i have no clear thoughts about howto.


best regards,




Liu Jian
2008-07-18