[olsr-dev] Plugin for dynamic proactive service discovery

[spoggle]

On 6/15/06, Rae Harbird <(spam-protected)> wrote:
> 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?

yeah, sort of...

the long answer is that in a proactive protocol i know where each and
every node in the network is and how to get there.  when i go to
determine a set of MPRs, i am guaranteed to have all the topology
information so i won't lose any nodes.

in a reactive protocol, i know where the active nodes are, but if a
node is sitting quietly and we don't have a route to it, we don't know
it exists - this node would not be accounted for in the set of MPRs.

consider a branch like this:

rest of the network ----- a ----- b ----- c

a & b are routing to each other, c is quiet

in a proactive mesh, a knows c exists and how to route packets to it,
and b would be an MPR - in a reactive mesh, a would not necessarily
know of the existence of c, and a might be the MPR leaving c without
an MPR neighbor.

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

that's what i'm thinking.

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

to my knowledge nothing was ever published

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