Currently, mod_smacks will send an <r/> after filling up the queue with stanzas (the default queue size is 0), and mod_csi_battery_saver will happily flush the buffer due to this being important.
As far as I understand it, however, mod_smacks will only see the stanzas after they got flushed by mod_csi_battery_saver, so it's not all that bad. However, it would be great to have mod_smacks actually only create the <r/> at the end of the CSI flush. It would also perfectly match my high-level idea of only asking for <r/> on actual user-written messages, as those are considered as important by CSI, and it would leverage the existing radio activity on mobile devices.
Furthermore, ~15% of <r/> requests are sent from handle_a, which as far as I can see is supposed to handle the situation when new stanzas were added while we were waiting for an ack? The respective addition is from https://hg.prosody.im/prosody-modules/rev/5fbca7de2088
Is this working as designed? Would it be possible to reduce the number of <r/> sent to make mobile connections stay idle for longer?
Zash
on
Changes
tags Component-Community
ge0rg
on
Yes, those are useful. Sending an <r> together with a client-requested <a> makes good use of the woken up client radio.
Other smacks related wakeup reasons are:
- connection timeout (no data sent / received for a longer time)
- resume and the following queue flush
Currently, mod_smacks will send an <r/> after filling up the queue with stanzas (the default queue size is 0), and mod_csi_battery_saver will happily flush the buffer due to this being important. As far as I understand it, however, mod_smacks will only see the stanzas after they got flushed by mod_csi_battery_saver, so it's not all that bad. However, it would be great to have mod_smacks actually only create the <r/> at the end of the CSI flush. It would also perfectly match my high-level idea of only asking for <r/> on actual user-written messages, as those are considered as important by CSI, and it would leverage the existing radio activity on mobile devices. Furthermore, ~15% of <r/> requests are sent from handle_a, which as far as I can see is supposed to handle the situation when new stanzas were added while we were waiting for an ack? The respective addition is from https://hg.prosody.im/prosody-modules/rev/5fbca7de2088 Is this working as designed? Would it be possible to reduce the number of <r/> sent to make mobile connections stay idle for longer?
Yes, those are useful. Sending an <r> together with a client-requested <a> makes good use of the woken up client radio. Other smacks related wakeup reasons are: - connection timeout (no data sent / received for a longer time) - resume and the following queue flush