On 06/22/2012 06:51 PM, Ed W wrote:
On 22/06/2012 11:23, Samuli Seppänen wrote:
First, is the primary purpose of the patch to save power on the mobile
clients? If so, wouldn't it be simpler to just have the client
disconnect when it notices that the connection is not being used and
reconnect dynamically when there's usage?
That appears to stop you sending stuff from the server to the client and
also breaks long running connections?
eg client connects to IMAP server, issues IDLE and waits for the mail
server to tell it that some new message has arrived in some folder. If
the connection isn't there then you can't hear a "new mail" response.
Equally if there is no new mail for 30 mins then you want to keep the
radio idle for as much time as possible
Just for reference turning on the radio in a mobile device is a
massively power hungry step. You can go from hours of battery life to
days of battery life if you can move from rapid wake ups (60s or less),
to less rapid wakeups (5-30 mins)
However, note to implementors. Most NAT devices close down UDP mappings
in 90s or less. Most TCP NAT mappings are kept open for much longer -
don't have the numbers in front of me, but I will guess at 10-30 mins
being a lower bound for most setups (many firewalls being massively
longer than that, eg 60min+). Therefore with a UDP VPN you will likely
need 60sec (worst case 90secs) keep alive packets to keep NAT pin holes
open. Keeping these packets tiny (\r\n) and not responding
unnecessarily is helpful... (halves the bandwidth)
But how does the OCC ping approach improve the situation over the currently
implemented --ping feature?
kind regards,
David Sommerseth
