[olsr-dev] Plugin for dynamic proactive service discovery

spoggle (spam-protected)
Fri Jun 16 00:17:21 CEST 2006

I think you have your terminology backwards - OLSR is proactive, AODV
is the opposite, an on-demand protocol (the OD in AODV)

Determining the set of MPRs really requires a proactive protocol.
On-demand protocols are missing the global information that allows the
set of MPRs to be determined.  In special cases it's possible the
information might be available in an on-demand protocol, and it might
be valid, but the reliability of packets passed via the MPRs would be
touchy.  A group that I know of was attempting to provide this sort of
information from an OD protocol, but last I heard it essentially
degenerated into a proactive protocol with all the disadvantages of

If you take away the MPRs, is there any reason why your plugin needs
to be associated with the routing at all?

dave c

On 6/15/06, Rae Harbird <(spam-protected)> wrote:
> Hi
> I am developing a service discovery plugin for OLSR. I have integrated
> some java service discovery code that I had already and OLSR by adapting
> the existing nameservice plugin and communicating between the two using
> xmlrpc. It was very successful.
> Now I want to dynamically change the behaviour of the routing daemon so
> that it behaves proactively (in an AODV-like way).  Again, I think that
> this will be fairly straightforward but there are some things I'm not
> sure about. I hope you will be able to point me in the right direction
> with some of these points:
> (a) Periodic route advertisements will not be needed in proactive mode.
> I'm guessing that deregistering the relevant olsr function from the
> plugin is easy enough. A hint on what to look at would be appreciated.
> (b) In proactive mode, service requests will be broadcast from the
> plugin in the usual way through the MPR set (which will equal the
> neighbour set).  Each node will continue to maintain its neighbour set
> so no change needed there.
> (c) AODV maintains routes between sources and destinations by recording
> the previous hop and the source from REQuest packets. I don't think OLSR
> messages contain a 'last hop' field so I will need to add one to the
> REQuest messages generated by the plugin. I understand how to register a
> function to process a REQ message when one is received.
> (d) I want to be able to send unicast UDP messages for replies, I' m not
> sure what the best way of doing this is. Should it just be some
> functionality I include in the plugin? Eventually I want to make the
> routing proactive as well. Do you have any recommendations?
> Many Thanks,
> Rae
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev

More information about the Olsr-dev mailing list