<div>i discussed this stuff today with henning,..<br></div><div><br></div><div>after discussing about various options that are quite complex #2, henning found a very simple one, which will work nearly as well,..</div><div>
<br></div><div>just send one (or maybe 2-3) hnas #1 with the minimal valid validity time (~ 1/16 second) at the old master (as soon as he knows he is the old master (probably because he received a hna-message from the new master))</div>
<div><br></div><div>this will update (the validity time) and in fact delete the old hna entry quite fast in the whole mesh</div><div><br></div><div>in some cases there might be loops, but in most cases everything works fine (and fast)</div>
<div><br></div><div class="gmail_quote">On Wed, Jan 20, 2010 at 10:49 PM, Raphael <span dir="ltr"><<a href="mailto:raphael@ralisi.de">raphael@ralisi.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi everybody </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
I still have some issues with the update on routes because the nodes<br>
do not communicate directly.<br>
<br>
I need help with adding new olsrd messages so that changing routes is<br>
fast enough to maintain voip-connections.<br></blockquote><div><br></div><div>beside the hnas to announce(and "delete") the client</div><div><br></div><div>i think you need an additional message type, to announce the mac of the client, so that new new master will (be able to identify) and use the same ip for its hna as the old one,</div>
<div>(or you calculate the ip from the mac-address) </div><div><br></div></div><div>Markus</div><div><br></div><div>#1 the normal hnas could even run at normal (or better quite normal) hna interval (and contain the maybe existing static hnas this node has aswell)<br>
(it still would be better to seperate the static hnas from the dynamic "client" ones, as different vtimes still make sense,..)</div><div><br>BUT the "deletion" hnas should clearly only contain the the hna for this single client.<br>
</div><div><br></div><div>#2 the complex solutions with tcs of virtual nodes, slowly changing link costs and a tunnel between old and new master try to</div><div>A work aorund intermittent loops<br></div><div>-> but it might be better to start with a simple approach to find out how many loops will actually happen *G<br>
B the fact that an hna can`t be deleted<br>-> and sending hna messages to reduce the actual validity time of this hna to 1/16 second, is extremely close to being able to delete it directly</div><div>---> it makes no sense to complicate things to gain 1/16 second<br>
</div>