Bad interaction between sleep timeouts and Salut?
tomeu at tomeuvizoso.net
Thu Sep 16 04:24:26 EDT 2010
On Thu, Sep 16, 2010 at 05:26, James Cameron <quozl at laptop.org> wrote:
> On Wed, Sep 15, 2010 at 08:04:25PM -0400, Martin Langhoff wrote:
>> I am curious -- what is the frequency of "presence broadcasts" when
>> Salut is used? Where is it set?
> Three minutes. Perhaps KEEPALIVE_TIMEOUT in
So Salut is an implementation of XEP-0174: Serverless Messaging:
In this section of the document is an overview of the different
components used by this protocol:
As you can see, basic presence is done with multicast DNS/DNS-SD and
Salut uses Avahi for that.
Gibber is a library internal to Salut that implements the other part
of the protocol: XMPP message passing between nodes.
With that in mind, what I would do next is to try to isolate the
problems within either Avahi or Gibber, that will reduce significantly
the amount of code we need to care about and will be useful in further
debugging and tuning. avahi-browse and avahi-discover are useful tools
for monitoring the state of Avahi, so if you could reproduce the same
issues there, then we could rule out a big chunk of code.
If that's the case, then these two functions in Salut would be most
relevant, the first announces a DNS service for the buddy and the
other does the same for shared activities:
Assuming the problem is in the Avahi level, we should make sure that
the system is coming out from suspend when the radio receives
multicast activity directed to us so Avahi can properly update its
internal state and also for activities using clique (multi-user chat
rooms on server-less XMPP). A couple more of references:
With Gabble we should see similar effects if the machine is not
resuming when the Jabber server sends us updates.
>> With current 10.1.2 using salut over ad-hoc the neighbourhood view
>> never stabilises, and it's very apparent that it's because nodes go to
>> sleep too quickly (before they see others, before they are seen). And
>> when awake, they take a long time to regain a good view of what's out
>> If we can experiment with the timeouts (knowing where the knobs are)
>> maybe we can find out...
>> (Tomeu, I bother you because I suspect you'd know... hope it's not an
> Salut over ad-hoc seems to use multicast packets, according to my
> tcpdump, so this source file appears relevant.
> The timers are specified there as constants, without configurable
> settings. So if you don't mind fiddling with them and recompiling, it
> should be possible to improve the situation, at the expense of increased
> wireless traffic.
> Might also detect resume, evaluate time interval lost, and expire the
> timer sooner.
> James Cameron
More information about the Devel