Changes between Initial Version and Version 1 of Ticket #1482


Ignore:
Timestamp:
Apr 10, 2012 5:59:18 AM (13 years ago)
Author:
bennylp
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1482 – Description

    initial v1  
    1919 1. '''Use a background task to ensure that the app doesn't suspend immediately after being waken up.''' App most likely will need to send something when it is waken up, for example some requests or TCP keep-alive data. Chances are these data will be responded by the server. If the app immediately gets suspended after sending them, it will be waken up again when the response arrives, hence adding to the wake up count. The app should delay as much as iOS allows before it goes to suspended state again, to take care the fact that some requests do take a while to complete, for example due to authentication. 
    2020 
    21  2. '''Fixing spurious wakeups problem'''. It has been reported that iOS may wake up the application every 10 seconds even when there is no activity in the network. This has been correlated to TCP transport disconnection, i.e. once the TCP transport is disconnected the app starts to get waken up every 10 seconds even when Wireshark shows no activity at all. We don't know the cause of this problem yet, but we think ticket #1465 and #1481 may help the situation. What these tickets do basically is to immediately close (or to close sooner) the TCP socket when we get disconnected. 
     21 2. '''Fixing spurious wakeups problem'''. It has been reported that iOS may wake up the application every 10 seconds even when there is no activity in the network. This has been correlated to TCP transport disconnection, i.e. once the TCP transport is disconnected the app starts to get waken up every 10 seconds even when Wireshark shows no activity at all. We don't know the cause of this problem yet, but we think ticket #1465 and #1481 may help the situation. What these tickets do basically is to immediately close (or to close sooner) the TCP socket when we get disconnected. If the app also holds a reference to the TCP transport, it should also release this reference once it gets the TCP disconnection notification (on the {{{on_transport_state()}}} callback), because the transport will only be destroyed once it's reference goes to zero. 
    2222