#10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut

[Simon Schampijer]

On 09/23/2010 03:55 PM, Tomeu Vizoso wrote:
> On Thu, Sep 23, 2010 at 15:30, Tomeu Vizoso<tomeu at tomeuvizoso.net>  wrote:
>> On Mon, Sep 20, 2010 at 12:56, Paul Fox<pgf at laptop.org>  wrote:
>>> tomeu wrote:
>>>   >  On Thu, Sep 16, 2010 at 23:38, Martin Langhoff
>>>   >  <martin.langhoff at gmail.com>  wrote:
>>>   >  >  On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso<tomeu at tomeuvizoso.net>  wrote:
>>>   >  >>  So the problem is that if you had to resync all state for each machine
>>>   >  >>  every time they wake up, you would use lots of bandwidth with the
>>>   >  >  (...)
>>>   >  >>  Another issue with this is that you not only want to resync presence,
>>>   >  >>  but shared activities also would need to resync their state.
>>>   >  >
>>>   >  >  Correct. My notes on the bug are probably unreadable -- it was late
>>>   >  >  last night, apologies.
>>>   >  >
>>>   >  >  What I mean to say is that we could
>>>   >  >
>>>   >  >  1 - explore the interaction between sleep timeouts and Salut resync
>>>   >  >  frequency for presence
>>>   >  >
>>>   >  >  2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual
>>>   >  >  collaboration session is running
>>>   >  >
>>>   >  >  I think #1 needs to be done regardless, as it'll improve behaviour
>>>   >  >  even if/when we our networking/suspend issues sorted. And some of the
>>>   >  >  issues in network/suspend interaction won't be easy to resolve.
>>>   >
>>>   >  I doubt there's much that can be done in Salut about it, should be
>>>   >  instead done inside Avahi. I would see how mDNS works, then look for
>>>   >  opportunities of tuning knobs in Avahi to speed up rediscovery:
>>>   >
>>>   >  http://tools.ietf.org/html/draft-ietf-dnsext-mdns-47
>>>   >
>>>   >  I'm going to ask around in case somebody has already thought of it and
>>>   >  can provide a shortcut.
>>>
>>> the laptop knows how long it was suspended, and this information could
>>> be made available to a resume hook (which almost exists, but not
>>> quite, in powerd) if it would be useful.  i.e., a a post-resume script
>>> could decide whether to kick the protocols to do something differently,
>>> if that was needed.
>>
>> Paul, what do you think about powerd implementing org.freedesktop.UPower ?
>>
>> http://upower.freedesktop.org/docs/UPower.html
>
> If so, Lennart could be interested in accepting a patch that makes
> Avahi listen for Resuming() and that implements the wake-up behavior
> as specified in
> http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt .

Thanks for that pointer and contacting Lennart. The funny part is: the 
draft expired yesterday :)

> After a quick read, looks like it would involve querying the network
> with the QU bit set so the other nodes can send unicast replies
> instead of multicast, thus saving bandwidth.

Yes the draft talks in section "5.5 Questions Requesting Unicast 
Responses" the case when using unicast responses instead of multicast 
responses in the resume case. The document states that after the first 
query multicast responses should be used. "Appendix D" contains some 
interesting points why using multicast responses is not inefficient.

Regards,
    Simon