[olsr-dev] Plugin for dynamic proactive service discovery
Fri Jun 16 02:27:44 CEST 2006
> I think you have your terminology backwards - OLSR is proactive, AODV
> is the opposite, an on-demand protocol (the OD in AODV)
Oh sorry! of course - I meant to say reactive, I need to learn a lesson
about sending messages too late
in the evening.
> Determining the set of MPRs really requires a proactive protocol.
Presume this is because we cannot assume the required level of stability
over a 2-hop span?
> On-demand protocols are missing the global information that allows the
> set of MPRs to be determined.
Because they do not usually maintain neighbour information through
> 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
True. Maybe it would be better not to use MPRs in reactive mode.
> 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
Is there any public information about the group? I'm interested to find out
> If you take away the MPRs, is there any reason why your plugin needs
> to be associated with the routing at all?
I am experimenting with routing & service discovery. Integrating routing
service discovery is not a new idea, it's been done with both proactive and
reactive algorithms. I want to try switching between proactive and reactive
modes of operation in response to context information, I don't want to
separate routing and service discovery.
> dave c
> On 6/15/06, Rae Harbird <(spam-protected)> wrote:
>> 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,
>> olsr-dev mailing list
> olsr-dev mailing list
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 318 bytes
Desc: not available
More information about the Olsr-dev