During the direct push process described above, the device waits for successive round trips before attempting to adjust the amount of time it needs to keep a connection open with the server. The amount of time that the server should wait for Personal Information Manager (PIM) changes or new mail to arrive before sending OK to the client is called the heartbeat interval.
The heartbeat interval is specified by the client and is sent as part of the ping request. The heartbeat begins at the default rate. The direct push algorithm on the client then dynamically adjusts the heartbeat interval to maintain the maximum time between heartbeats without exceeding the time-out value. The adjustment is based on network conditions and how long an idle HTTP or HTTPS connection can be maintained on the operator or corporate network and some settings that the operator can specify.
To determine the optimal heartbeat interval, the algorithm keeps a log of ping requests. If a ping request receives a response, the algorithm increases the interval. If no response is received at the end of the interval, the client determines that the network timed out and the interval is decreased.
By using this algorithm, the client eventually determines the longest idle connection possible across the cellular network and corporate firewall.
The following illustration shows how the heartbeat interval is adjusted during typical direct push communication between the client and the Exchange Server.
The "T" in this illustration indicates the progression of time.
The following steps describe the communication; the numbers correspond to the numbers in the illustration:
1. The client wakes up and issues an HTTP request over the Internet to the Exchange Server, and then goes to sleep.
To keep the session active, the request states the heartbeat interval, which is the amount of time that the server should wait for Personal Information Manager (PIM) changes or new mail to arrive before sending OK to the client. In this illustration, the heartbeat interval is 15 minutes.
2. Because no mail arrived during the heartbeat interval, the server returns an HTTP 200 OK.
In this example, the response is lost because either the operator network or the Enterprise network was unable to sustain the long-lived HTTP connection; the client never receives it.
Note
If the connection is closed by the front-end Exchange server, the device will acknowledge the ended session and immediately reconnect.
If the connection is closed by the back-end Exchange server, the device does not acknowledge the ended session and waits for the end of the heartbeat interval to reconnect.
3. The client wakes up at the end of the heartbeat interval plus 1 minute (15 + 1 = 16 minutes total).
Note:
The device waits for successive round trips before attempting to adjust the heartbeat interval. A tuning component in the algorithm can change the increments to an amount different than what is specified.
If this was a successive round trip with no response from the server, it issues a shorter-lived request (8 minutes).
In this example, because the heartbeat was not increased during the last ping, the heartbeat is changed to the minimum heartbeat value (8 minutes).
4. Because no mail arrived during the heartbeat interval, so the server returns an HTTP 200 OK.
5. The server response wakes up the client. Because the connection did not time out during the interval, the client determines that the network can support idle connections for at least this length of time.
If this was a successive round trip, the client determines that it can increase the interval to a longer time for the next request.
| 