Re: Salut/avahi/meshview issues
2008-02-01 00:05:17 GMT
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.I believe our current salut/avahi issues are described in the following points:
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?
_______________________________________________ Devel mailing list Devel <at> lists.laptop.org http://lists.laptop.org/listinfo/devel