[Olsr-dev] Client Roaming Plugin

[marc fawzi]

>>p.s. we can switch to german i think (-;

:-(

I think the idea of using olsrd to provide a way for mobile devices with
conventional wifi capability to switch between olsrd-enabled wifi
accesspoints without losing VoIP connection is a very important telephony
application of OLSR that seems to be very practical from a business
perspective in the near term.

I'm keeping my fingers crossed and hoping that it can be done. It's far
easier from a business perspective than requiring mobile phones to be in
ad-hoc mode and running olsrd.

Sorry to interject my non-technical opinion, but I would hope you guys
continue in English ;-)


On Thu, Jan 21, 2010 at 4:25 PM, Markus Kittenberger <
(spam-protected)> wrote:

> > 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 (-;
>
> --
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100121/92df0288/attachment.html>