[olsr-dev] Plugin for dynamic proactive service discovery

[spoggle]

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
both.

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
>