[Olsr-dev] First release of IP Autoconfig daemon (PAA)

Hannes Gredler (spam-protected)
Fri Nov 30 11:06:33 CET 2007

On Fri, Nov 30, 2007 at 09:11:14AM +0100, Roar Bj?rgum Rotvik wrote:
| Reading your statement "move in PAA code from the plugin to the core of the 
| olsrd" makes me wonder if you have understood the two parts in PAA as 
| described in the start of this email. The paa-plugin may be moved to the 
| olsr core, but I don't see the reason for it.
| I'm not sure that moving the PAA daemon into olsr would bee a good idea.
| Some issues:
| * Today PAA need to acquire an IP address _before_ starting olsr, since 
| olsr in the past did not like changes/addition of IP-addresses on one of 
| it's interfaces.

well thats one of the weaknesses that we hope to address as part of
the olsrd-ng initiative. taking care of all sort of interface
dynamics )if up/down, addressing changes).

| I don't know if the current olsr would like for a plugin to change/add IP 
| address on a running interface?

thats my point i do not want to have plugins messign around with the
interface states and that is specific one of the reason why i would like
to have the paa functionality in the core of the olsr code.
because of the tighter integration less risks for race-conditions etc.
since we are in the process of rewriting the interface handling it
would just be a good idea to intgrate PAA.

| * If olsr is still single-threaded it could hurt routing performance to 
| implement even more processing in the single-thread event loop in olsr.

we have highly optimized the message processing and SPF runtime in the last
4 releases (in fact the last optimization of the rt computation code-path
i have on the boilerplate now only uses 0.3% CPU on a standard WRT54GL router,
based on a 300 node topology. so we have now significant headroom in
adding new functionality - autoconfiguration is certainly one of
them and high up on the wishlist.

| * PAA daemon uses a thread (to generate FORWARD_REQ messages). I don't know 
| if you would like threads inside olsr.
| My priority list is as this for now:
| * Add copyright and license to the paa-plugin source code
| * Release paa-plugin source code (hope to release it during next week)
| * Fix up paa-plugin to work against current olsr (currently it is coded to 
| work against uolsr-0.4.3).
| * Test and make PAA work, also in some bigger networks
| Regarding relicense the PAA daemon to BSD and incorporate it into olsr; I'm 
| not against the idea but someone need to convince me that it is smart (and 
| I may need management approval) :)

well flexibility how we arrange the code later is always smart, right ? 

| But first I would like to make it work as it is against current olsr 
| release..



More information about the Olsr-dev mailing list