[Olsr-dev] olsrd etx + plugin

[Erik Tromp]

Thanks Henning for you quick answer.

Just a few more stupid questions (resulting from my ignorance ;-)

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.

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?

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?

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?

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?

Thanks in advance for your effort.

Best regards,
Erik


> Each lq_plugin defines a large struct which contains all 
> necessary pointers for the olsr-core to use your lq-metric 
> without knowing what you are doing (see struct lq_handler in 
> src/lq_plugin.h). The structure changed a little bit from 
> 0.5.6 to the development top so we could get rid of the void* 
> pointers. Both versions allow you to add additional parts to 
> several internal databases of the OLSR and allow you do 
> handle (de-)serialization of the LQ part of TCs/Hellos 
> yourself. All you have to give back is a "link cost" value 
> which is just a unsigned integer (maximum allowed value is 
> ~2^24 to prevent an integer overflow during dijkstra).
> 
> the layer2metric development tree adds a "layer 2" metric 
> database which is filled by a plugin (/lib/ll_linux_nl80211) 
> directly from a recent mac80211 link wlan stack (2.6.29 or 
> better, 2.6.28 + compat-wireless will work too).
> Unfortunately noone had enough time to test the prototype to 
> get some experience on layer 2 metric, we had/have too much 
> todo with the normal OLSR core at the moment and creating a 
> firmware with 2.6.29 so we get an user base which is able to 
> run the linklayer metric code.
> 
> My plans for the future of this tree is to test what happens 
> if I switch the OLSR to raw sockets for package handling, so 
> I get the mac address of each neighbor for free (see 
> arprefresh plugin). Then we would have to create a good and 
> flexible linklayer database and some lq-plugins which use it 
> to calculate ETT and similar stuff.
> 
> If you are interested, just tell me. I think the olsr.org 
> implementation is much closer to a linklayer based metric 
> system (maybe ETT for example) than you 0.5.5 fork, but we 
> need more manpower to test/experiment with it so it can be 
> included into 0.5.7 (or maybe 0.5.8).
> 
> Henning
> 
> *************************************************
> Diplom Informatiker Henning Rogge
> Forschungsgesellschaft für
> Angewandte Naturwissenschaften e. V. (FGAN) Neuenahrer Str. 
> 20, 53343 Wachtberg, Germany
> Tel.: 0049 (0)228 9435-961
> Fax: 0049 (0)228 9435-685
> E-Mail: (spam-protected)
> Web: www.fgan.de
> ************************************************
> Sitz der Gesellschaft: Bonn
> Registergericht: Amtsgericht Bonn VR 2530
> Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), 
> Prof. Dr.-Ing. 
> Joachim Ender (Stellv.)
> 
>