[horde] ActiveSync problem

[Simon Wilson]

----- Message from Michael J Rubinsky <mrubinsk at horde.org> ---------
    Date: Thu, 21 Jul 2011 10:12:39 -0400
    From: Michael J Rubinsky <mrubinsk at horde.org>
Subject: Re: [horde] ActiveSync problem
      To: horde at lists.horde.org


> Quoting Simon Wilson <simon at simonandkate.net>:
>
>>> Mike - thanks, on first check setting a forced heartbeat seems to  
>>> have resolved it. I made an edit and it went through very quickly.  
>>> Will follow up and look in more detail at the parameters that can  
>>> be set later.
>>>
>>> I had looked at heartbeat but discounted it as the description  
>>> inferred to me that it was server to client, which seemed to be  
>>> working fine.
>>>
>>> Simon
>>
>> Hmmm... having a forced heartbeat seems to possibly be sucking dry  
>> the battery on my iPhone. By this stage of the day I'm usually  
>> still at 50% battery left, I'm down to 17% at the moment. Even a  
>> reboot to make sure nothing else is chewing memory hasn't slowed it  
>> down.
>
>
>> Mike, can you elaborate on what the heartbeat tries to do? I have  
>> it set to $conf[activesync][ping][forcedheartbeat] 25 and  
>> $conf[activesync][ping][waitinterval] 15 at the moment. What does  
>> that force the phone to do?
>
> Essentially with these values you are forcing the phone to make more  
> frequent (but shorter) requests.
>
> The server receives a PING, notes the current time (lets call this  
> {request_time}), adds {heartbeatinterval} seconds to it and then  
> polls history for changes.  The server then waits for  
> {waitinterval}, then checks to see if {hearbeatinterval} +  
> {request_time} has passed yet. If not, it polls history again.  
> Rinse. Repeat. When {heartbeatinterval} + {request_time} has passed,  
> the PING response is sent to the device and the request ends. It is  
> then up to the device to decide when to send another PING. This is  
> not something that Horde can control. On iOS, this is usually done  
> almost immediatley (you can control this by turning off Push, and  
> setting a specific interval on the i[Phone|Pod|Pad] settings).
>
> So, what you are doing by using forcedheartbeat is telling the  
> server that when it receives a PING, ignore the heartbeatinterval  
> that the device is sending (I forget what it is on the iPhone, but  
> IIRC it's something along the line of a few mintues), and force the  
> request to terminate after a set period of time. With your settings,  
> it stays connected for appoximately 25 seconds, and probably polls  
> history twice during each request.
>
> All this being said, I don't remember exactly what problem I was  
> attempting to solve for you by telling you to tweak this, and the  
> thread history is gone from this reply. If it was to assist in the  
> device picking up server side changes to the calendar, this was  
> likely fixed by one of the recently discussed commits.
>
> -- 
> mike

Mike - thanks... I am only working with Contacts at the moment,  
Calendar is too broken. The issue that prompted the change to forced  
heartbeat was not server -> client - that has always been almost  
instantaneous, and does not change with either forced- or device  
managed-heartbeats - but client -> server. With heartbeat set to  
device managed, after a client based edit or addition the device  
visually tries to connect for anything between 30 - 45 minutes before  
the change successfully reaches Turba. An Apache restart forces  
immediate sync of the change.

Once forced heartbeat is set, the sync of a change to the server takes  
_approximately_ whatever I have set  
$conf[activesync][ping][forcedheartbeat] to. So at the moment, to  
reduce battery life impact, I have it set to 120 seconds. A change on  
the iPhone / iPad generates a busy symbol on the iOS device for  
approximately 2 minutes, before the change is reflected in Turba.  
Bring it down to 20, and the delay is about 20 seconds, but the  
battery is flogged.

I'll have a concentrated read through your description and do some  
more testing over the weekend.

Simon.