Salut/avahi/meshview issues

[Giannis Galanis]

On Jan 31, 2008 10:54 AM, Ricardo Carrano <carrano at ricardocarrano.com>
wrote:

>
> I believe our current salut/avahi issues are described in the following
> > points:
> >
> > 1. I was under the impression that when a peer switches channels it
> > sends a "goodbye signal". And in fact only anorthodoxically removed
> > peers(after crashes/poweroffs by pressing the button etc) would delay to
> > disappear from mesh views.  The 10min TTL is not unreasonable, but it should
> > only be used for a routine check. In fact peers that leave/arrive should
> > inform the mesh instantly. In that case the 10min TLL will only affect only
> > the mesh points with noisy links that their "goodbye" signals will get lost.
> > And these connections are less priority anyway. Also we could send 2/3
> > "goodbye" signals to "ensure" delivery.
>
>
> Mm, it seems that some dbus signal or the respective processing by the PS
> lacks. Is there a NM dbus signal when we change channels? This should be
> easy to determine.
>
> >
It must be very easy for the PS to detect a channel change, or anyway when
the XOs leaves the channel. The point is whether avahi supports such
notifications, so the other peers can instantly remove the entry.


>
> > 2. We should definitely decrease the timeout window between a lost peer
> > being detected, and the actual disappearance from the mesh view. This used
> > to be 10min, now it is 20min, but really, to my experience, if a peer is for
> > more than 1-2min away he aint coming back.
>
>
> For what you describe this does not seem related to the protocol itself,
> right? I believe it is important to achieve our goals without making the
> protocol more chatty.
>
> >
This timeout is client specific, and doesnt affect the protocol itself at
all. There reason this timeout exists(to my knowledge anyway), is that
sometime a peer seems indiscoverable, but in fact it is just the effect of a
poor link. So the peer rejoins shortly after. The effect would be XOs would
move around the mesh view. To solve this issue, we wait for several minutes,
before actually removing the XO.
To my opinion the more we hide from the user, the more she gets confused.
Keeping the icon in the mesh view while the connections is down, just messes
things up.
I also remember that there was the idea of keeping the "lost" icon in the
mesh view, but notifying the user somehow, like change its outline to a
dotted line or smth. But, this is a UI issue


>
> >
> > 3. Should we make the above TTL and timeout to be user specific, or
> > custom anyway?. Will there be a problem if two XOs have different TTL? I
> > would assume that it wont. The idea is that it is a waste of our resources
> > to try to calculate the ideal values of TTL and timeout by asking the
> > collabora team to fix, and fix again. Whereas we can make the test here in
> > 1cc, and find ourselves which suits as best. Is it easy to implement such a
> > patch?
>
>
> I believe it  is useful to have  some controls  in order to help  tuning
> things up.  But not all of them need to be translated in user friendly
> controls. I believe your question would be how we could change this setting
> ourselves. Did I get it right?
>
> Exactly. By no means we need to have this controls user friendly. We only
need the ability to tune them dynamically our selves for testing and
evaluating purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080131/8c1eac08/attachment.html>