Salut/avahi/meshview issues

[Ricardo Carrano]

> 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.


>
>
> 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.

>
>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080131/50049810/attachment.html>