[Olsr-dev] olsrd etx + plugin

[Henning Rogge]

On Dienstag 21 April 2009 16:00:57 Erik Tromp wrote:
> Thanks Henning for you quick answer.
>
> Just a few more stupid questions (resulting from my ignorance ;-)
I assume that you look at the development tip. The 0.5.6 branch contains an 
outdated version of the lq_plugin system.

> 1. I see all source/header files of a plugin start with
> lq_plugin_default... and are located in /src . If I write an LQ-plugin,
> would you suggest putting the source files under /src and naming them e.g.
> lq_plugin_default_ett.c/h ? Maybe it is an idea to create a special
> sub-directory for LQ-plugin files, since the LQ-handling is (in my opinion)
> a crucial part of a good MANET protocol.
We keep all lq_plugins in the /lib directory, except the "default" one.

> 2. Why does every function start with the word 'default'? Is it because all
> three currently provided LQ-plugins implement the old 'default' metric, the
> ETX metric? In that case, can I assume that a new plugin would not be
> called 'default' any more? Would it be an idea to rename all current
> LQ-plugin source/header files starting with 'lq_plugin_default...' to
> 'lq_plugin_etx...' so that it is clear which algorithm is implemented?
the "default" plugins are compiled into the main olsr executable, the others 
are plugins in the /lib directory. We have to keep one lq-plugin in the main 
source to be able to run OLSR if the user wrecks it's library path.

The plugins in the /lib directory have more "normal" names like 
"lq_etxfloat_memorize_foreign_hello"...

> 3. What do the abbreviations 'fpm', and 'ff' stand for? In the debug output
> I read "Using 'etx_fpm' algorithm for lq calculation." What is the reason
> for choosing the 'etx_fpm' algorithm as the default of the three currently
> provided plugins?
etx_float = float based etx
etx_fpm = fix point math etx (integer arithmetik)
etx_ff = etx (freifunk/funkfeuer variant), calculates the etx value with a 
different algorithm

> 4. Apparantly each LQ-plugin may define its own layout of TCs/Hellos. Is
> there any limitation to this freedom? I can see for example that all of the
> currently provided default_lq_serialize_.... functions use 4 bytes (of
> which 2 unused). Could another plugin use, say, 16 bytes? Or 256 bytes?
theoretically yes I think, unless I missed a "length of LQ" somewhere in the 
source.

> 5. Is there interworking between varius LQ-plugins? If not, I assume that
> it is up to the MANET administrator to provide every node in the MANET with
> the same (compatible) LQ-plugin. Is there any way that the LQ plugin system
> can detect that other nodes are running non-compatible LQ-plugins?
The three ETX plugins should be compatible... the RFC one is not.

so yes, the admin have to choose the right plugin, there is no space in the 
OLSR package format to transmit version numbers of plugin ids... but we might 
do this when we switch to OLSRv2/PacketBB...

Henning

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20090421/fe56b0d6/attachment.sig>