[Olsr-dev] Client Roaming Plugin

[Markus Kittenberger]

> which is impossible todo inside olsr,

> I wonder what you mean by this, because before working on C, I tested
> this idea with a bash script(which only included ping, route add and
> route del), and my handover-time was less then a second.
>

no i meant impossible inside the whole mesh
it is no problem for the master-nodes to do it fast,..
but its hard to convince the wohle mesh to do the same,..

but in the meantime, i realised that in theory it can be done quite fast,
(using tcs (of hypothetic olsrd-nodes) to company the hnas, as tcs can
overwrite old, which plain hnas can't)
so u can force the typical olsrd-mesh within the time one broadcast flooding
needs, to forget the old position/gateway of a client and to learn the
new,..

so it might be quite easy & fast to get the new topology information, into
the mesh

BUT i still have some doubts that some of the typical configured nodes in
the mesh will need up to 10 seconds to recalculate their routes, and
therefore boycott this new topology (and the routes based on it) a bit

(but in maybe 1-2 years we will probably have olsrd that can adopt such
topology changes really fast, but this requires multiple (already planned)
improvements)

>
>
> > (you would need to change every olsrd in your mesh, to learn them to do
> > timely synchronised routing changes)
> every olsrd with a accesspoint-function. agreed.
> I think we can assume that on a handover, the two accesspoints
> involved, are (two hop) neighbours on OLSR.

hmm why can you assume this?

the client may be on a spot seing two freifunk nodes that can not see each
other, and do not share any neighbours aswell

and even if they are, this does not help very much, as the targets the
client device wants to exchange data with might lie somewhere far away in
the mesh, (but even a node 1 hop away may insist to wait some seconds until
it recalculates its routing table, causing a intermittent loop until it
does,..)

but too make things clear, it will work in about 80-90% #1 of usecases quite
well, and im just continuing to find a solution for close to 100% #2 *G

#1 assuming that the next gateway to internet is quite near, and typical
usecase is traffic into the internet

#2 i already have one really ugly method, and one very complex, that will
still probably fail (at least with mutliple roaming events)


> If i client roams, it is
> most important that the old accesspoint has a route pointing towards
> the new accesspoint. The rest shouldn't be very important.
>

e.g. expect problems if you want to voip from and to clients/nodes in the
mesh (having some hops between)

Markus

p.s. we can switch to german i think (-;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100122/aa30aa6c/attachment.html>