Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: iOS reconnect troubles

  1. #11
    Junior Member
    Join Date
    Nov 2011
    Ah interesting!

    If PHP returns a payload to the webserver (to be sent to the user) I'm not sure there's a practical way to detect that the payload never made to to the client (ie the connection became stale)

    So, long ping is running... change detected, change reported to user php completes, but payload never reaches client.

    However, I've noticed that the device subsequently attempts to "ping" but doesn't detect the change...

    Normally.. I imagine this is how it works normally....

    Ping, change detected, change reported to client
    sync, changes collected, changes delivered to client.
    Ping, etc.....

    But with a poor connection:

    Ping, change detected, change report fails to reach client
    Ping, wait for more changes.

    Would it be worth investigating repeating the result of the last ping if no sync has happened since the previous ping and no changes are immediately available?
    I feel like the spec should have more about "failed" pings...

    I'm hoping not to waste your time teaching me the intricacies of activesync... so I'll do more digging..

    I'm interested as to why its not a problem for android / windows... it doesn't surprise me that apple might be much more sensitive..

  2. #12
    Senior Member
    Join Date
    Nov 2007
    Belo Horizonte, Brazil
    Hi cpitchhord,

    If there weren't changes during ping request, the server responses with status 1 (no changes) and the device then issues a new ping request. For that to work the mobile device of course has to receive the response from the server.
    There is no way Z-Push can repeat the result of last ping (or any other command) because Active Sync protocol relies on a client server architecture and the client always issues the request to which the server responds.

    That's a good question to which we (Z-Push developers) don't have an answer. Only that there apparently are differences in how every vendor implements long term connection handling, network connection management via wifi/mobile data and last but not least the ActiveSync protocol itself. I'd be very happy to hear if you manage to dig something up in this matter.

    Please do not PM me asking for support. Use the forum instead. Thank you.
    I usually check the mobility thread at the end of the day, so please have some patience if there's no immediate response. Asking to look at certain thread per PM won't result in a faster answer.

  3. #13
    Junior Member
    Join Date
    Nov 2011
    That's not quite what I meant, but I see what you mean..

    However, what I was thinking was more a "re-transmit on request" approach:

    What I think I've seen from the logs today:

    1) IOS sent ping request
    2) time passes
    4) IOS moves from wifi to 4G
    3) Z-push detects change
    4) Z-push tries to send response, not delivered
    5) More time passes
    6) IOS sends new ping request
    7) Z-push waits for a new change (i.e new mail to arrive)

    Because ios missed the response of the first ping, it ends up waiting for another new email to arrive before it updates / syncs

    What I imagine is a normal conversation:

    1) IOS sends ping
    2) Z-push waits for change
    3) Change detected
    4) Z-Push sends change response to IOS
    5) IOS sends Sync command
    6) Z-Push sends changes
    7) IOS sends another ping request
    8) Z-Push waits for another new change

    After a change detected ping, the device should sync...

    So its:

    1) Ping - change detected
    2) Sync
    3) Ping....

    However when it's broken its (the first ping change detected fails to arrive)

    1) Ping - change detected
    2) Ping...

    So, could we use that pattern to detect a ping was missed by IOS?
    If we knew that a ping was missed when a new ping request is made, we could immediately re-send the previous change detected

    1) Ping cmd received
    2) If pending ping result exists:
    2a) SEND pending ping result - we'll immediately send the previous ping response
    2b) CLEAR pending ping result - we'll clear it so we don't repeat it a third time
    2c) done
    3) no pending ping result exists
    4) wait for change
    5) STORE change as pending ping result - Incase we couldn't successfully reply to the device
    6) send ping results (which might fail)

    1) CLEAR pending ping result - If we're syncing, we don't need any previous ping results
    2) carry out sync

    That was kind of what I was thinking.

    I'm going to investigate exactly what changes are stored by z-push state when a ping is returned:

    a) it records which changes were detected so it doesn't re-report them
    b) it doesn't record anything, the state only changes after a sync action
    c) something else.

    The risk is, if we receive ping and report it... then the device ignores the ping and immediately pings again.. we'd keep sending a single duplicate... so I want to find out why a device wouldn't sync following a change..

  4. #14
    Senior Member
    Join Date
    Sep 2007
    Aka SebastianBrasil
    Hey cpitchhord,

    if a change response is lost and never reaches the client, the server will return the same notification for this folder when the phone connects again to do another ping.
    The notification itself, as you suggested, is not stored, but from the states we check for pending changes before entering the wait-for-changes mode on a new ping connections.

    So, these notifications are not lost. I would say that iOS just doesn't initiate a new ping connection. It just does nothing and when you open the mail app on the phone it will just go "oh, true, I should sync. Well here are your new mails...".


  5. #15
    Junior Member
    Join Date
    Nov 2011
    This is what I thought it should do... However, I think what I'm seeing on my setup (dovecot, sabredav, combined+imap+caldav+carddav) is that the change response to a ping cmd only actually fires if z-push observes a change (i.e a new mail arriving) and not if there was a previous change ready to be collected/synced.

    I didn't have enough time last weekend to build a clone of my mail setup just for playing and testing...but I hope to have that running later this week.

    I spent some time working through the imap stuff (seeing as this is the most problematic for me at the moment) and I think I'm getting to understand the flow of the process inside z-push.

    I was initially scared of the trace/debug level of logging... but I'm getting reacquainted with WBXML (I wrote a C++ WAP gateway in 2001, so it comes flooding back!)

    I'll collect hard evidence of strangeness, either way.. and report back

  6. #16
    Senior Member
    Join Date
    Sep 2007
    Aka SebastianBrasil
    Hey Chris,

    cool that you are looking into this. We are always searching for new IMAP/CardDav/CalDav contributors and reviewers, so, every interest and any help is very welcome!

    There are several ways of detecting a change in a folder in Z-Push:
    - via the exporters - for every folder we save a state that changes with every change that happens on a store/per request. The imap/caldav/carddav backends use the Diff engine to calculate these changes (save a list of the items we had last time, get the current list, compare them -> see what changed). This list of changes is "the ultimative truth" and is the general fallback method and always need to work. Unfortunately it's also the slowest option.

    - via FolderStats: this is basically any blob that "changes whenever something in the folder changes". It's checked by Sync and before entering Ping if it differs to the last time a change happened. Folderstats is an optimization introduced in Z-Push 2.3 (especially for Outlook as OL syncs all folders per request). As most of the times in a big folder structure changes happen in single places, it prevents the exporters to be checked too frequently. Afaik this functionality is not (yet) implemented for imap/caldav/carddav or the combined backend. The fallback is checking the exporters.

    - via ChangesSink - used in ping and Sync-heartbeat connections. The sink blocks until a change in a subscribed folder changes. In imap this is realized with data returned by imap_status() which is checked periodically. When the sink informes a change it's checked via the exporters before a notification is sent to the client (this is important, as the specified sync window might not be affected by the change).

    Knowing this:
    - Sync does a folderstats check on the requested folder, if it changes changes are retrieved with the exporter and sent to the device. If folderstats are not available, the exporter is always requested.
    - Ping does check folderstats for all requested folders. If they indicate a change the notification is immediately sent to the device (without blocking). The following Sync command should then export the change and update the saved folderstat, which is then checked again with the next Ping request.

    Before diving into folderstats too much, ping should work fine without it. It should run an export and this should re-sent the notification, as the exporters should still see this change.
    Still, folderstats can probably be implemented into IMAP quite easily by reusing the data retrieved via imap_status(). Not sure if the combined backend is adapted for this already.


Page 2 of 2 FirstFirst 12

Similar Threads

  1. SQL reconnect Errors
    By darootler in forum Administration and Integration
    Replies: 0
    Last Post: 26-09-2014, 08:02 AM
  2. Z-push 2.0.6 / Nokia N9 Troubles (Addressbook)
    By rickstinson in forum Z-Push when using Kopano/Zarafa
    Replies: 1
    Last Post: 04-02-2013, 04:59 PM
  3. SQL Reconnect error
    By kaya in forum Installation, Configuration and Maintenance
    Replies: 5
    Last Post: 28-11-2011, 10:12 AM
  4. [SOLVED] Troubles installing Zarafa Client 702
    By niels1 in forum Installation, Configuration and Maintenance
    Replies: 4
    Last Post: 18-11-2011, 08:41 AM
  5. Outlook Profile creation troubles...
    By ern64 in forum Outlook client
    Replies: 7
    Last Post: 14-10-2011, 11:08 PM


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts