[8125, K-JAM, P4300, MDA Vario General] Sleuth255:
Having just returned from MEDC where "direct push" technology was drilled into my head ad-nauseum through lecture and lab, I can succinctly say that AUTD v1.0 (sms trigger) and AUTD v2.0 (https heartbeat, also known as "direct push") are identical. Only the trigger component is different.

Let's first of all get something straight: It is always the WM device that "pulls" change deltas using wireless activesync. Precisely defined, "changes" are differences in the syncronization state of the Exchange mailbox and the WM mailbox. Examples of things that will change this state on the exchange host are receiving a new email or deleting a message, or adding/deleting/changing contacts or adding/deleting/changing calendar entries. The exact list of these are the exchange components you check when you set up AUTD.

Making these same changes on the WM device does not initiate a re-sync however. Sending a new email (if you have "send immediately" checked) or choosing sync in the WM activesync application or choosing send/recieve from the pocket outlook menu are the only things that can initiate the activesync process from the WM device.

What is actually transferred using this pull process are deltas of the state changes themselves, compressed using a GZIP compression algorythm.

now the trigger logic.

In AUTD v1.0, when the mailbox state goes out of sync, a special SMS message is sent to the WM device which contains information identifying the SMS message itself as being from a trusted sync source. Additionally, the SMS message contains a sync command that is signed by the trusted source. The WM device then initiates a wireless activesync and pulls the change deltas required to bring its outlook database back in sync with the exchange hosted outlook database (also called the "mailbox").

In AUTD v2.0, the trigger method is replaced. When WM directpush activates, either during bootup or when "direct push" is tapped in the comm manager, a HTTPS connection is established with the Exchange system and a HTTP GET request is issued via that connection. If the exchange database for the user has changed since the last request, a sync response is issued and the WM device pulls change deltas in the exact same way as it does in AUTD v1.0. If there are no changes, then exchange updates the last request time and no reply is issued. However, the device is marked as "online". Now, when a WM device is marked as "online" and the exchange database changes, the same sync response described above is issued via this (still should be) open channel and an activesync is initiated. If the channel is closed (because the device was turned off or the DHCP address was changed by the GPRS operator) then nothing is done other than marking the device as "offline".

If there is no activity for 8 minutes (default) then the WM device issues another HTTP GET and the process continues. This has the added benefit of re-opening a closed connection btw. As I alluded to above, the connection might be closed for many reasons including a DHCP lease change by the operator or perhaps a firewall session timeout. If the exchange system doesn't see this "heartbeat" in 10 minutes (changable) then the WM device is marked as "offline". M$ has calculated this heartbeat overhead as somewhere around 2KB/month of data transfer IIRC.

The battery power required to send this 2KB/month is, in a nutshell, the difference between battery drain in AUTD v1.0 and AUTD v2.0.

If you are seeing 8 minute lags between message receipts, then look to DHCP lease changes (browsing to www.myipaddress.com can tell you this) or change the default timeout on your ISA server. USA direct push enthusiasts might want to note that Cingular's Medianet proxy changes IP addresses quite frequently when it is busy btw. I have better success with instant mail delivery when I use "My ISP" rather than "MediaNet" as my Internet connection.