<br><font size=2 face="sans-serif">And what worries me even more is that
we will further cripple the laptop by always turning off local-link collaboration
every time we are able to contact *any* jabber server. I really don't want
to have the MPP fiasco repeated....</font>
<br>
<br><font size=2 face="sans-serif">Jabber servers on the local network,
need to be able to identify themselves (even with mDNS or a predefined
anycast address) and then and only then we can turn mDNS off.</font>
<br>
<br><font size=2 face="sans-serif">M.</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>John Watlington <wad@laptop.org></b>
</font>
<p><font size=1 face="sans-serif">12/14/2007 12:43 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"Giannis Galanis" <galanis@laptop.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">John Watlington <wad@laptop.org>,
"Michail Bletsas" <mbletsas@laptop.org>, "Kim Quirk"
<Kim@laptop.org>, "Ricardo Carrano" <carrano@ricardocarrano.com>,
guillaume.desmottes@collabora.co.uk, "Robert McQueen" <robert.mcqueen@collabora.co.uk>,
"Simon McVittie" <simon.mcvittie@collabora.co.uk>, devel
<devel@laptop.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: The reason we see icons flashing
here and there in the mesh view.. i.e. "xmas tree effect"</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2><br>
What worries me most about this is the revelation that we continue to  <br>
rely on mDNS<br>
when connected to internet infrastructure.  When in the presence of
a  <br>
school server,<br>
(or connected to a jabber server), mDNS should be shut down.    <br>
Otherwise we risk<br>
a network meltdown....<br>
<br>
wad<br>
<br>
On Dec 13, 2007, at 11:18 PM, Giannis Galanis wrote:<br>
<br>
> I had several tests related to the xmas tree effect we see in the
 <br>
> mesh view.<br>
><br>
> The effect is that some times XOs disappear + reappear to the same
 <br>
> or different position, or simply disappear. More usually it happens
 <br>
> for many XOs simultaneously.<br>
><br>
> The results i have, clearly indicate that this is an issue an the
 <br>
> Avahi daemon, which is used by the Salut telepathy service. The  <br>
> sugar interface displayes the information it receives from salut  <br>
> very reliably. This means that when a host dissapear from the  <br>
> avahi's host list, it vanished instantly from the mesh view, and  <br>
> the same when a new host arrives.<br>
><br>
> The Avahi deamon runs below Salut and keeps receives information  <br>
> from other hosts in the network which also run Avahi deamon.<br>
> It keeps a local cache with the recent hosts.<br>
> At regular intervals(of 1-2 mins i think), it checks whether the  <br>
> hosts in the cache are alive. If not, they are recorded as "failed"<br>
> The above check can be invoked by "avahi-browse -t -r  <br>
> _presence._tcp"  continuously(instead of waiting for 1-2mins)<br>
> After a certain timeout, a failed entry(dead host) will disappear
 <br>
> from the cache, and instantly it will disappear from the mesh view.<br>
><br>
> This timeouts is pretty long(several minutes), so a host(XO) has  <br>
> the chance to become alive again with no effect on the mesh view.<br>
> This can occur when:<br>
> a. the XO's avahi packets dont get through due to high mesh  <br>
> traffic. In this case the other XOs might either see is as alive,
 <br>
> or dead according to the conditions.<br>
> b.the XO's deliberately moved to another channel, or anyway  <br>
> disconnected. In that case, all othes XOs will see it as dead<br>
> From a client's point of view, the two cases are treated almost the
 <br>
> same.<br>
><br>
> THE TEST:<br>
> 6 XOs connected to channel 11, with forwarding tables blinded only
 <br>
> to them selves, so no other element in the mesh can interfere.<br>
><br>
> The cache list was scanned continuously on all XOs using a script<br>
><br>
> If  all XOs remained idle, they all showed reliably to each other
 <br>
> mesh view. Every 5-10 mins an XO showed as dead in some other XOs
 <br>
> scns, but this was shortly recovered, and there was no visual  <br>
> effect in the mesh view.<br>
><br>
> If you switched an XO manually to another channel, again it showed
 <br>
> "dead" in all others. If you reconnected to channel 11,
there is  <br>
> again no effect in the mesh view.<br>
> If you never reconnected, in about 10-15 minutes the entry is  <br>
> deleted, and the corresponding XO icon dissapeared from the view.<br>
><br>
> Therefore, it is common and expected for XOs to show as "dead"
in  <br>
> the Avahi cache for some time for some time.<br>
><br>
> THE BUG:<br>
> IF a new XO appears(a message is received through Avahi),<br>
> WHILE there are 1 or more XOs in the cache that are reported as "dead"<br>
> THEN Avahi "crashes" temporarily and the cache CLEARS.<br>
><br>
> At this point ALL XOs that are listed as dead instantly disappear
 <br>
> from the mesh view.<br>
> But, of course, some of the "dead" XOs are expected to re-appear
 <br>
> shortly. Specially those that are still in the same mesh channel,
 <br>
> but merely failed to transmit its avahi packets due to traffic load.<br>
><br>
> Note that if there is only 1 XO that looks dead, but returns,  <br>
> everything is normal.<br>
> But, if there are 2,3.. XOs that look dead, when 1 returns, then:<br>
> a. all(the dead ones) disappear from the view<br>
> b. the 1 that returned will reappear right after in probably a  <br>
> different position. i.e. it will "jump"<br>
><br>
> The avahi-browse command scans realtime the network(i.e. sends  <br>
> requests for all hosts in its cache list) and runs for a several  <br>
> seconds. If the above situation occurs, it freezes(this is what i
 <br>
> meant by "crashes"). When it is restarted the cache is cleared
from  <br>
> previously dead hosts.<br>
><br>
> A typical situation that the "xmas tree effect" occurs:<br>
> 20 XOs are running salut in channel 1. This incuded XOs conencted
 <br>
> to medialab AP, schoolserver, linklocal.<br>
> XOs leave the channel continuously.<br>
> Concurrently, some connected XOs appear dead for 1 minute or so,  <br>
> and reappear after short time.<br>
><br>
> Assume that at some point 5 XOs have either really left, or "seem
 <br>
> dead" anyway<br>
><br>
> At some point 2 of these XOs are reconnected at the same time to  <br>
> the mesh channel by someone in the office.<br>
> The 2 XOs will "jump" to a different position, whereas the
other 3  <br>
> will simply vanish<br>
><br>
> The way I see it, there is very clear/narrow/specific bug in  <br>
> handling the cache by the avahi daemon,<br>
> when new hosts + dead hosts coexist.<br>
><br>
> I hope the tests have cleared the picture alot<br>
><br>
> yani<br>
> _______________________________________________<br>
> Devel mailing list<br>
> Devel@lists.laptop.org<br>
> </font></tt><a href=http://lists.laptop.org/listinfo/devel><tt><font size=2>http://lists.laptop.org/listinfo/devel<br>
<br>
</font></tt></a>
<br>