Direct push-Great

Direct push --- Great

Abstract: The Push Mail business has become increasingly active in China. The popularity of Exchange Server and smart phone PDA has also largely reflected the informatization level of enterprises (companies. This article describes the implementation conditions, implementation mechanism, heartbeat correction process, and firewall configuration. Keywords
Direct push, Exchange Server 2007, email

About a month ago, he talked to Bob Li about the principles of direct push. At that time, he promised to write something about push e-mail, it is a pity that the previous section was too busy, and the time for surfing the Internet was limited every day, so it was only a little relief until now. I hope you will be able to contact me more.

Background

Push is relative to pull, and the traditional email is actually a pull method. The initiative lies in the user. When they log on to their mailbox, they will ask whether the email server has a new email, if there is a new email, the client will check (download) The new email to the inbox. We can think that:

Pull = user request + server push

However, since the email itself is a message from the sender to the recipient, why cannot it be directly pushed to the user like a short message (SMS? In fact, this is the significance of the traditional pull method:

The client is flexible

The necessity of the email server is that it is always connected to the network, and users are randomly connected. The email server cannot and does not need to address the user, because the user only occasionally accesses and may access different networks each time. When a new mail arrives, the mail server cannot determine the address to which the new mail should be sent. Therefore, only user-initiated requests are allowed. The common Post Office Protocol (POP3) is a pull-based mail protocol.

Internet Message Access Protocol (IMAP) provides support for the email reminder (Inquiry) function. When the mail client receives a reminder from the server, it can choose whether to go to the server to obtain new data. The ability to choose whether to obtain new emails is a major feature of IMAP. This method is obviously more flexible than pull-only systems. On the other hand, this reminder message method undoubtedly increases the number of round-trip interactions, which is a little tedious.

Next we will talk about the main character of this article --- direct push

Direct push is a feature built in Exchange Server 2007. It is used to connect a mobile device through the carrier's cellular network and maintain a state that is always updated with a specific server (always-up-to-date.

TipsIn fact, the concept of direct push is introduced when Exchange Server 2003 sp2 is: you can referHttp://msdn2.microsoft.com/en-us/library/aa446486.aspx

Direct push introduces an active reminder mechanism, which you can call as "active IMAP" J. This mechanism makes every time new content is to be synchronized to the device, the device receives a message ).

Direct pushConditions

1) mobile devices

First, your mobile device must support direct push. Generally, OEMs will emphasize this point. For example, when I start i718, there will be a "direct push technology" logo. The following conditions must be met:

Ø a Windows Mobile 5.0 device with the phone function and messaging & Security Feature Pack (msfp) (of course, a later version is also supported ).

A mobile device (not necessarily a Windows Mobile Device) that is licensed by Microsoft Exchange ActiveSync and designed to be compatible with direct push ).

2) servers

Exchange Server 2007

Direct pushOverview

Next let's take a look at how a typical Push Mail works. By default, direct push is enabled in exchange2007. Mobile devices that support direct push initiate an HTTPS persistent connection request to the Exchange Server. At the same time, the Exchange Server monitors the mailbox activities of its users and sends a response to the mobile device when the mailbox status changes.

!The "Mailbox status change" mentioned here is widely used. It may be because of the arrival of a new email, the deletion of the email, or any change in the calendar or contact.

If such changes occur during the lifecycle of the HTTPS persistent connection request, the Exchange Server immediately initiates a response to the user's mobile terminal to remind the mobile device of new changes, you need to re-Synchronize the mobile device to the Exchange Server to obtain the updated information, and then the mobile device will initiate a synchronous request to the server. After the synchronization is complete, a new long-connection HTTPS request will be generated again and again. Such repeated requests ensure that users' email, calendar, contacts, tasks, and other information are pushed to mobile devices in a relatively timely manner, this allows you to synchronize updates with the Exchange Server even if they are not on the PC.

Direct pushTopology

Figure 2 describes the topology of a typical Exchange Server 2007 direct Push configuration.

Figure 2 network model of direct push

The following figure shows how direct push works:

1) a mobile device configured to synchronize with an Exchange Server 2007 initiates an HTTPS request to the server. This request is what we usually call Ping. This request tells the server that it will send a reminder to our transfer device when any folder of the user on the email server changes in the next 15 minutes. In the next time, our mobile devices will be on standby, waiting for messages. The 15-minute interval is the heartbeat interval.

2) If no entries change within the 15 minutes, the server returns an HTTP 200 OK message. Our mobile devices receive this message, return to the active status, and initiate a new request.

3) In the heartbeat within 15 minutes, if there is any change or a new entry is received, the server will send a response notifying the mobile device that some new emails or email entries have changed, and tell the mobile device the name of the folder that has changed. After a mobile device receives the message, it initiates a request to synchronize the message with a changed folder and the updated content on the server. When synchronization is complete, the mobile device initiates a new Ping request, and then starts a new heartbeat.

Direct pushCorrection mechanism

Direct push depends on a network environment that supports HTTPS persistent connections. What if the network or firewall of a mobile device does not support HTTPS requests with persistent connections? Next let's take a look at how direct push works when the transmission network timeout time is less than the heartbeat time:

(Assume that the network timeout time of the mobile device is 13 minutes)

1) a mobile device initiates an HTTPS persistent connection request to the server. In the next 15 minutes, we hope to receive a notification when the user's folder on the email server changes. If there is no change, the server should return an HTTP 200 OK message, which is exactly the same as before.

2) If the server does not respond to the mobile device within these 15 minutes, the mobile device may infer that the connection to the server has timed out. It will re-initiate an HTTPS request, but this time it will use an eight-minute heartbeat request.

3) eight minutes later, the server sends an HTTP 200 OK message. The device then tries to initiate an HTTPS request for a longer period (12 minutes) to the server.

4) if you receive a new email within these 12 minutes, the server will send a notification to the mobile device prompting you that new content is waiting for synchronization. Then, the device synchronizes with the server and re-initiates the 12-minute request.

5) if no new or changed content is received after 12 minutes, the server will reply to an HTTP 200 OK message. Then the device will infer that the current network condition is 12 minutes heartbeat, and it will continue to try to use a longer (16 minutes) connection.

6) after 16 minutes, there was no response. At this time, the mobile device will infer that the current network does not support heartbeat for 16 minutes. Because this timeout occurs after the device tries to increase the heartbeat interval, the transferred device knows that the maximum timeout interval of the current network has been reached, and the device does not reduce the interval to perform repeated operations, instead, it takes the last successful heartbeat time (12 minutes) and re-initiates the 12-minute heartbeat.

All in all, a mobile device stores the ping request log, which uses an algorithm to try to use the longest allowed heartbeat interval to initiate a connection request. This increases the standby time (after each request, if the user does not have other operating devices, the device will be suspended) and reduces network traffic.

The heartbeat connection time can be found in the mobile device registry.

Configure direct push to work across firewalls

Almost no enterprise's intranet is directly connected to the Internet, and usually a server acts as a firewall. To prevent direct push from being blocked by the firewall, you must first open TCP port 443, which is required by SSL. Make sure that the port is opened between the user's access server and the Internet.

In addition to opening necessary ports in the firewall, in order to improve the performance of direct push, the firewall timeout value should be increased. If the firewall closes the session, emails will not be delivered, until the next connection. Therefore, the firewall session time should be set to a wider range than the carrier's idle network timeout time. It generally takes 15 to 30 minutes. We can see from the previous analysis that it is clear that the shorter the timeout time, the more frequent connection requests of mobile devices, this will reduce the standby time and increase network traffic. For more information about configuring the firewall, see ISA Server product documentation.

Recommended Resources

Microsoft Exchange team

Microsoft direct push Homepage

Ø heartbeat interval Adjustment

Yellow winter <fox23>

Hjd. Click at gmail.com

May 17, 2008