[Olsr-dev] olsrd etx + plugin
Tue Apr 21 16:00:57 CEST 2009
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
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
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.
> 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).
> 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.)
More information about the Olsr-dev