>><meta charset="utf-8">p.s. we can switch to german i think (-;<div><br></div><div>:-( </div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div>
<div>Sorry to interject my non-technical opinion, but I would hope you guys continue in English ;-) </div><div><br></div><div><br><div class="gmail_quote">On Thu, Jan 21, 2010 at 4:25 PM, Markus Kittenberger <span dir="ltr"><<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">> which is impossible todo inside olsr,<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wonder what you mean by this, because before working on C, I tested<br>
this idea with a bash script(which only included ping, route add and<br>
route del), and my handover-time was less then a second.<br></blockquote><div><br></div><div>no i meant impossible inside the whole mesh</div><div>it is no problem for the master-nodes to do it fast,..</div><div>but its hard to convince the wohle mesh to do the same,..</div>
<div><br></div><div>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)</div><div>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,..</div>
<div><br></div><div>so it might be quite easy & fast to get the new topology information, into the mesh</div><div><br></div><div>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</div>
<div><br></div><div>(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)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
<br>
> (you would need to change every olsrd in your mesh, to learn them to do<br>
> timely synchronised routing changes)<br>
</div>every olsrd with a accesspoint-function. agreed.<br>
I think we can assume that on a handover, the two accesspoints<br>
involved, are (two hop) neighbours on OLSR. </blockquote><div>hmm why can you assume this? </div><div><br></div><div>the client may be on a spot seing two freifunk nodes that can not see each other, and do not share any neighbours aswell</div>
<div><br></div><div>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,..)</div>
<div><br></div><div>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<br></div><div><br></div><div>#1 assuming that the next gateway to internet is quite near, and typical usecase is traffic into the internet</div>
<div><br></div><div>#2 i already have one really ugly method, and one very complex, that will still probably fail (at least with mutliple roaming events)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If i client roams, it is<br>
most important that the old accesspoint has a route pointing towards<br>
the new accesspoint. The rest shouldn't be very important.<br></blockquote><div><br>e.g. expect problems if you want to voip from and to clients/nodes in the mesh (having some hops between)<br></div></div><font color="#888888"><div>
<br></div>
<div>Markus<br></div></font><div><br></div><div>p.s. we can switch to german i think (-;</div>
<br>--<br>
Olsr-dev mailing list<br>
<a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-dev</a><br></blockquote></div><br></div>