[olsr-dev] Plugin for dynamic proactive service discovery

[Rae Harbird]

spoggle wrote:

> 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 
HELLO messages?

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


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

Is there any public information about the group? I'm interested to find out
more.

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


Thanks


Rae
====






> 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
>>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: r.harbird.vcf
Type: text/x-vcard
Size: 318 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20060616/27cf6288/attachment.vcf>