How does Direct Push really work?

From the earlier section “When nudge comes to shove: How push is Direct Push?”, we talked about three methods of retrieving Email available to Windows Mobile 5.0 devices onwards – by polling, Direct Push, or manually.

All three methods of retrieving your Email ride on top of your standard mobile technologies such as GPRS, EGPRS and 3G etcetera. Now, compared to AUTD, Direct Push might appear to be more complicated, but how it works is really quite trivial if you have a good idea of how the Internet works. Even if you don’t, do try to follow-through my explanation as knowing how Direct Push communicates with Exchange will allow you to trouble-shoot so much more effectively. Additionally, later sections such as traffic optimization will assume that you have a good idea of the mentioned.


Upon startup, your supported Windows Mobile device will initiate a TCP/IP connection with your (already configured) Exchange 2003 SP2 server. This TCP/IP connection can either be unencrypted or encrypted (recommended) using SSL. Of course, if you opt to use encryption (SSL), then you will either have to purchase a proper digital certificate from a vendor or create a self-generated (free) one and manually importing it into your Pocket PC.

Note that as of the time of writing that it is entirely possible that your particular Pocket PC device or Smartphone does not support importing of self-generated digital certificates and/or only support a limited number of root certificates. As it is, it would be prudent to do some basic research before committing any money into your handheld (if you have not purchased one yet), or shelving out money for a commercial certificate. We will go more into this later.

Back to Direct Push: once a data connection is established, certain information and settings are exchanged between the device and Exchange. An ActiveSync is then initiated that will determine if any actual data synchronization is necessary. If it is, a full ActiveSync will occur. If no synchronization is required, then no further data transfer happens. Regardless if any full ActiveSync occurs or not, the interesting part comes after this.

In a typical Internet connection, what normally happens is that the data connection is closed once data transfer is finished. In the case of Direct Push, the socket connection is kept open between the device and server. Note that this is not an abnormal or any proprietary aberration by Microsoft in the using of the IP protocol. Keeping a connection open is actually allowed for in TCP/IP. We encounter this on a daily basis in the form of KEEP-ALIVE requests usually sent from web servers to our web browsers. In fact, it is very similar to how Internet Message Access Protocol (IMAP) mail servers are architected around - in which a combination of IDLE and NOOP commands are used to periodically poll the server and keep the network connection alive.

In the case of Direct Push, the Exchange server will keep monitoring the relevant set of folders for changes. The relevant set of folders to be monitored is already transmitted by the Windows Mobile handheld as part of the data exchange in the connection process.

When a change in the monitored folder(s) is detected the Exchange Server will send a byte of data back to the handheld using the existing data connection. This will tell the Windows Mobile device to perform an ActiveSync - which will allow the relevant changes to be retrieved. If a change occurs on the handheld set however - the user sends an Email for example, then the handheld will initiate the ActiveSync with Exchange immediately to update the server. Note that unlike AUTD, not only are deleted or moved items detected, even changes in read status on either the handheld device or Exchange server via Outlook client is detected and synchronized accordingly.

Because the entire Direct Push process is done via a standard Internet socket connection, the key advantage is that no special network provisioning or setup is required anywhere. There is no need for your telco to offer support or perform a special “provisioning” for you, unlike a Blackberry.

However, it must be said that there is an inherent risk that the idle connection might be silently dropped by a myriad of factors. This could range from application or network firewalls, timeouts or dropped packets due to poor network connectivity. If this happens - as it invariably will due to poor mobile coverage at certain locations, then theoretically push mail will grind to a complete and permanent halt if the handheld never realizes that the connection has been lost.

To prevent this, the concept of a heartbeat time interval is implemented. At the end of every heartbeat (Default in AKU2 is 480 seconds, or 8 minutes), the handheld will perform a PING by attempting to send some data back to the server. If the PING fails a five times in a row, then the connection with the server is torn down and re-established from scratch. Because performing a PING involves sending data, it is hence possible to optimize one's traffic usage by manually specifying a larger PING interval. More on this later.

Now, if you are technically-minded at all, the thought might have crossed your mind after reading my above explanation about how Direct Push works: "But this sounds more like pull mail than push mail isn't it?". Indeed, there has been debate by some parties on the purity of just how 'push mail' is Direct Push. My personal take on this is very simple: If it tastes like hamburger, looks like hamburger, smells like hamburger - and is edible; is there a need to really care about the thawing and cooking process? Besides, there are distinct advantages in Microsoft’s architect which we will look in the next section.