Review Request 121711: Modify how the TCP socket established between kdeconnect and the device is set up for keep alive. Use IPPROTO_TCP instead of the getprotobyname method for setting keep alive characteristics and use the QTcpSockect object's own setSocketOption to activate keep alive instead of going via setsockopt.

Mon Dec 29 08:59:37 UTC 2014

> On Dec. 29, 2014, 5:12 a.m., Albert Vaca Cintora wrote:
> > apparle just commented on IRC that this change may affect battery life. It shouldn't have a big impact because the keepalive packet is handled by the OS instead of the app itself, but just in case, I will set it to a more conservative value, like 10 or 15 seconds.
> 
> Pramod Dematagoda wrote:
>     I don't know if the difference between power usage would be significant either way, if we were looking at the power usage by the network adapter then the fact that we wait for a longer time before we start sending packets out to verify that the connection still exists would not result in much, if any, power being saved. Even if we were looking in terms of power usage based on the fact that no activity occurs, this still would not be true because the keep alive packets will eventually be sent out if the device has disconnected.
>     
>     This also considering the gains we get in terms of kdeconnect being faster to detect a disconnected device which would be advantageous, especially for the screensaver inhibit plugin (shameless self plug there :P).
> 
> Albert Vaca Cintora wrote:
>     I mean the battery life of the phone, that has to wake up to reply to the keepalive packages more often, not the computer.
> 
> Pramod Dematagoda wrote:
>     Well in that case the idle period still would not make a huge difference, all we might gain is about 10 seconds (with a 15 second idle) (and this assuming that kdeconnect is the only thing keeping the phone awake) extra where the phone has the opportunity to go to sleep before it has to wake back up for the keep alive packets.
>     
>     I wouldn't mind increasing the idle time, but I just think it isn't worth it for what little extra battery time it might give us.
> 
> Albert Vaca Cintora wrote:
>     But for the same reason, it's not a big difference to have the phone incorrectly appearing as connected for 10 seconds instead of 5, and it would require half of the communication with the phone.
> 
> Pramod Dematagoda wrote:
>     It would be the same amount of communication though, with the 10 second wait we just wait 5 seconds more before we decide to start sending the keep alive packets, the number of packets sent doesn't change. The only reason this 5 second extra wait might help is for usage patterns of active -> idle -> active over a long period of time (but even for this I wager the gain is almost negligible). Plus if the device was to actually be disconnected, then the device would not be woken up by these packets anyway.
> 
> Albert Vaca Cintora wrote:
>     If I understand correctly, when there is no activity it will send a packet every 5 seconds vs one every 10 seconds. So in 1 hour that would be 720 times that the phone will wake up vs 360 times.
> 
> Pramod Dematagoda wrote:
>     No, that's the idle, it would start sending those packets after 5 seconds of the connection being idle in the current configuration, it would actually send a keep alive packet every 2 seconds (it was every 5 seconds under the previous configuration). But even if we extend the time between sending packets I would believe that the savings would be almost none. And yes, we could save on the number of packets we send out, but I don't believe that would necessarily translate to power savings directly.
> 
> Albert Vaca Cintora wrote:
>     Okay, sorry, then it's not a big deal to tune that parameter down, but I would not lower the interval to 2 seconds. There is no need to be so agresive with that: if the device is really gone, we have waited 5 seconds anyway for the keepalive to kick in. If the device is not gone (this is what will happen most of the times), we will be sending lots of unnecessary packets.
> 
> Pramod Dematagoda wrote:
>     There is a paper I found (http://www.slideshare.net/Sandra4211/tcp-wakeup-reducing-keepalive-traffic-in-mobile-ipv4-and) that supports my argument (page 4) that keep alives (on WLAN at least) are pretty inexpensive (to the point that there is approximately a 250mW saving from sending packets every 10 as opposed to 2 seconds). Keeping in mind that this was in 2008 and it is quite likely that hardware has become more efficient to reduce this difference now.
>     
>     I realise that the paper is about an alternative to keep alive but still :P
>     
>     In the end though I am happy to increase the duration between packets (maybe the number of keep alives could be decreased to 2 to compensate). What number would you be happy with?
> 
> Albert Vaca Cintora wrote:
>     The reason I'm being conservative here is because there are lots of users with different hardware and we want to be extra sure that we won't cause battery problems to any of them. Specially for a not-so-important reason as disconnecting the device early. It is useful for your screensaver-inhibit plugin, but in most of the cases is not a big deal. With the current parameters it takes over 70 seconds to disconnect a device, and I agree that it's too much, but there is no need to cut it down to 10 seconds either. Setting the values to 10 and 5 it will take 20 seconds to disconnect a device (10 for the initial packet + 5 for the second + 5 for the third), and I think that should be enough even for your screensaver inhibition use case. Are you okay with that?

Fair enough, you have your reasons and as you mentioned the difference between the different times is not that significant. I'll send a patch out with that, and the issues previously mentioned fixed up.

- Pramod

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121711/#review72662
-----------------------------------------------------------

On Dec. 28, 2014, 11:11 a.m., Pramod Dematagoda wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121711/
> -----------------------------------------------------------
> 
> (Updated Dec. 28, 2014, 11:11 a.m.)
> 
> 
> Review request for kdeconnect and Albert Vaca Cintora.
> 
> 
> Repository: kdeconnect-kde
> 
> 
> Description
> -------
> 
> Adjust the parameters used to set keep alive for the device's TCP socket to try and detect device disconnection faster.
> 
> Currently kdeconnect does not seem to properly detect that a device has disconnected, even after a few minutes have elapsed since the device has disconnected, this patch set aims to fix this so kdeconnect detects a disconnected device faster.
> 
> 
> Diffs
> -----
> 
>   core/backends/lan/lanlinkprovider.cpp 39d30370ce225d1979f395fc20f26b23f0e791f1 
> 
> Diff: https://git.reviewboard.kde.org/r/121711/diff/
> 
> 
> Testing
> -------
> 
> Given that a phone is connected to kdeconnect.
> When the phone's wireless is switched off.
> And approximately 10 seconds pass.
> Then kdeconnect detects that the device has disconnected and reflects this fact.
> 
> 
> Thanks,
> 
> Pramod Dematagoda
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20141229/7cbd8885/attachment.html>