回 2楼(wave14) 的帖子
回 4楼(tonyunreal) 的帖子
[strike]呃,,,这"心跳消息"怎么看上去还是"定时抓取"...只是通过https协议而不是POP3/IMAP协议....XD
还是说,这心跳消息仅仅起维持会话作用,有新信息时,服务器会主动发送消息到客户端?[/strike]
微软Direct Push技术不是使用SMS消息，而是靠在移动设备和Exchange Server之间维持一个常HTTPS连接来发挥作用的。因为这个连接总是处于可用状态，所以有新电子邮件的消息就几乎能即时转发给移动设备。
Direct Push使用“心跳消息”(heartbeat messages)来保持Exchange服务器与移动设备之间的会话连接。所谓“心跳”，仅仅是指周期性发送一些消息来保持会话连接，允许移动设备检查同步过程是否有必要。
当移动设备开始与Exchange Server的会话时，这一过程就开始了。在这一过程中，移动设备以预先定义的间隔发送“心跳”消息给服务器。此时，有以下3种情况之一发生。
1. Exchange服务器以新的同步数据作为响应。这种情况下，新的数据与存储在移动设备中的数据进行同步。
2. Exchange服务器以HTTP 200 OK消息作为响应。这意味着没有同步新的数据。更为重要的是，这还表示会话没有超时。
当移动设备收到这个响应时，也许会尝试动态调整它的“心跳”间隔，因此心跳间隔的时间周期会变长。要知道，“心跳”间隔时间越长，电池消耗越低。更长的“心跳”间隔也减少了“心跳”被潜在语音呼叫打断的可能性。
3. 会话在“心跳”间隔时间到来前超时。这种情况发生时，为了防止Direct Push会话超时，Exchange会自动减小“心跳”间隔。
我们可以很清楚地看到Direct Push会话是如何通过发送“心跳”消息并等待响应来保持的。然而，根据我上面的描述，还似乎有很多未解决的偶然性。举例来说，Exchange Server如何知道“心跳”间隔调整的幅度为多大?或者如果有中断通信过程的意外事件发生会怎样呢?
但是在实际过程中，却没有这么多的偶然性。微软在动态调整Direct Push“心跳”技术中积聚了很多人的才智。
微软明白那些引起“心跳”异常的因素。举例来说，如果Exchange服务器突然比预期繁忙，于是服务器就不太可能在超时之前对心跳消息进行响应。如果是这种情况，Exchange Server设计了在调整好直接推送“心跳”间隔之前必须出现连续往返“心跳”的机制。
微软在Direct Push中凝聚集体智慧的另一个表现是Exchange Server很聪明地知道，如果已知心跳超时的原因，它就不应该调整“心跳”间隔。
比如，如果用户正在电话上通话，这时Exchange Server发送了一个“心跳”响应，那么移动设备将永远不会收到这个响应，于是“心跳”就会超时。然而，Exchange Direct Push知道超时只会出现在用户正在通话的情况下，因此不会调整“心跳”间隔。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/charles1900/archive/2008/01/22/2060001.aspx
==================================================================================================================
Direct Push概述 下面来看看一个典型的Push Mail的工作过程是怎样的。默认情况下，Direct Push在Exchange2007中是被启用的。那些支持Direct Push的移动设备向Exchange Server发起一个HTTPS的长连接请求。同时，Exchange Server对它的用户们的邮箱活动进行监视，并能够在邮箱状态变化的时候给移动设备发送一个回应。 ！这里说的“邮箱状态变化”的范围是很广的，可能是新邮件到来，可能是删除了邮件，也可能是日程表或者联系人的任何变化。 如果这样一些改变发生在那个HTTPS长连接请求的生命周期内，Exchange Server会立即发起一个回应给用户的移动终端，提醒该移动设备有了新的变化，须要重新同步移动设备到Exchange Server以获取更新的信息，然后移动设备会发起一个同步的请求给server。同步完成以后，一条新的长连接HTTPS的请求又会生成，如此反复。这样反复的请求，保证了用户的Email,日历，联系人和任务等信息都会相对及时地被Push到Mobile设备，使得用户即便不在PC机前也可以与Exchange server保持一个同步更新的状态。 | 
沪公网安备 31010702007642号 )
发表于 2011-2-20 04:29
