本申请要求以下申请的优先权:美国申请号为60/437869、代理人记事号220635、于2003年1月3日提交、题为“改进的客户机服务器通信的系统和方法”(SYSTEM AND METHOD FOR IMPROVED CLIENT SERVER COMMUNICATIONS),该申请通过引用被结合于此。
(5)具体实施方式
在继续描述本发明各实施例之前,现在将提供对其中可实践本发明各实施例的计算机和网络环境的描述。尽管不需要,本发明可以用计算机所执行的程序来实现。一般而言,所述程序包括能执行特定任务或实现特定抽象数据类型的例程、对象、组件、数据结构等等。这里所使用的术语“程序”意味着单个程序模块或共同作用的多个程序模块。这里所使用的术语“计算机”包括电子地执行一或多个程序的任何设备,譬如个人电脑(PC)、手提设备、多处理器系统、基于微处理器的可编程用户电子设备、网络PC、微型计算机、平板PC、大型计算机、具有微处理器或微控制器的用户设备、路由器、网关、集线器、等等。本发明也可以用于分布式计算环境中,其中由通过通信网连接的远程处理设备来执行任务。在分布式计算环境中,程序既可位于本地存储设备中,又可位于远程存储设备中。
现在将参考图1描述其中可使用本发明的网络环境的示例。示例网络包括在云所表示的网络11上互相通信的几台计算机10。网络11可以包括许多公知组件,譬如路由器、网关、集线器等,并且允许计算机10通过有线和/或无线媒介进行通信。当在网络11上彼此作用时,一台或多台计算机可能充当客户机、服务器、或与其它计算机的对等方。因而,本发明的各个实施例可以在客户机、服务器、或它们的组合上实践,即使这里所包含的特定示例不是指所有这些类型的计算机。
参考图2,它示出计算机的基本配置示例,该计算机上可实现本发明的全部或一部分。在最基本的配置中,计算机10一般至少包括一个处理单元14和存储器16。处理单元14按照本发明各实施例执行指令来实现任务。在实现这些任务时,处理单元14可以把电信号发送到计算机10的其它部分,并且发送到计算机10外部的设备以引起某些结果。根据计算机10的实际配置和类型,存储器16可以是易失性的(譬如RAM)、非易失性的(譬如ROM或闪存)、或者两者的某些组合。图2中用虚线说明了最基本的配置。另外,计算机可能还有附加的特征/功能。例如,计算机10可能还包括附加的存储器(可移动存储器201和/或不可移动存储器202),包括、但不限于磁盘或光盘或磁带。计算机存储媒介包括以用于存储信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动的媒介,信息包括计算机可执行指令、数据结构、程序模块或其它数据。计算机存储媒介包括、但不限于:RAM、ROM、EEPROM、闪存、CD-ROM、数字化视频光盘(DVD)或其它光学存储器、磁盘卡带、磁带、磁盘存储器、或其它磁性存储设备、或者可用于存储理想信息并可被计算机10存取的任何其它媒介。任何这类计算机存储媒介都可以是计算机10的一部分。
计算机10最好还包括允许设备与其它设备通信的通信连接205。通信连接是通信媒介的示例。通信媒介一般把计算机可读指令、数据结构、程序模块或其它数据包含在已调数据信号中,譬如载波或其它传送机制,并且包括任何信息传送媒介。例如、但不限于,术语“通信媒介”包括像有线网络或直线连接这样的有线媒介,以及像声学、RF、红外这样的无线媒介及其它无线媒介。这里所使用的术语“计算机可读媒介”既包括计算机存储媒介,又包括通信媒介。
计算机10可能还包括诸如键盘、鼠标、输入笔、语音输入设备、触摸输入设备等等这样的设备204。也可以包括输出设备203,譬如显示器20、扬声器、打印机、等等。所有这些设备都是本领域公知的,并且无须在此讨论。
本发明针对用于改进的客户机和服务器通信的系统和方法,尤其针对可用于在客户机和服务器间通信的改进的协议。本发明尤其关于邮件服务器环境,但是这里所描述的特征也可以用于其它客户机和服务器网络。然而为了描述的简便,参考客户机/服务器邮件环境而描述本发明。
本发明可以在客户机/服务器环境中实现,该环境具有两种或多个版本的客户机应用程序或组件,以及/或者两者或多个版本的服务器应用程序或组件。为此,图3说明了一框图,示出网络邮件环境中客户机和服务器组件的多个版本。通常,配置客户机和服务器组件,使它们向后兼容。也就是,客户机组件能够与最新和传统版本的服务器组件通信,反之亦然。建立了一组协议在多个版本间通信。这组协议可以组成几个不同协议,每个都是自包含的。或者,一组协议组件可用,而特定的组件用于配置协议组内的特定协议。
任何情况下,在图3所示的网络邮件环境中,最新版本的邮件客户机组件303能用协议307最佳地与最新版本的邮件服务器组件306通信。然而,最新的邮件服务器组件306也能用协议组内的其它协议(如,图3内的协议308和309)与所选择的在前版本的邮件客户机组件通信,例如,邮件客户机组件302和邮件客户机组件301。邮件客户机组件303也能用诸如协议310和311这样的协议与所选择的在前版本的邮件服务器组件通信,例如,邮件服务器组件305和邮件服务器组件304。
一般而言,如这里所使用的,为了描述本发明的协议,“最新的”邮件(服务器或客户机)组件,即最新版本的邮件(服务器或客户机)组件,是知道新的特征和所述特征的服务器或客户机组件,并且可以使用、实现和/或作用于那些特征。尽管本文档中通篇使用了这些术语来描述知道本发明协议各方面的客户机和服务器组件,然而这些术语也包括仅知道所述特定方面、或不止所述一方面的组件。同样,“在前”邮件组件(即在前版本的邮件组件)是不知道、并且不能作用于本发明协议各方面的组件。
通常使用协议协商过程来建立客户机和服务器(如,最新版本的邮件服务器组件306和最新版本的邮件客户机组件303)之间的协议。尽管这种协议协商是已知的,然而仍为读者提供了对邮件客户机组件401(图4)和邮件服务器组件402间协议协商过程的简要描述。起初在邮件客户机组件401和邮件服务器组件402间的通信会话中,邮件客户机组件401向邮件服务器组件402发送一包括客户机版本信息的信息403,例如,以客户机组件版本标志(stamp)的形式。邮件服务器组件402用包括客户机版本信息的信息404对信息403应答,例如,信息404是以服务器组件版本标志的形式。
为了试图在邮件客户机组件401和邮件服务器组件402间建立通信,可以以多种方式使用客户机和服务器版本信息。例如,可以用版本信息来为继续通信选择适当的协议,或者来确定进一步的通信是否可行。例如,在建立协议时,可以用版本信息来启用和/或禁用特定可用的协议方面或组件。
邮件服务器组件可能并行地接收并处理来自多个邮件客户机组件的请求。在示出单个客户机之处,除非特别指出,这仅仅为了简化附图和所附说明。
本发明的邮件网络使用请求和应答交换在网络内的客户机和服务器组件间传送查询和数据。实践中,协议性能可能受到基本(underlying)通信网络传送机制的影响,该机制用于在邮件网络内实现客户机和服务器之间的通信。例如,在使用远程过程调用(RPC)作为基本通信网络传送机制的邮件网络内,使用较大尺寸(如,32KB)的单个远程过程调用可能远比使用几个较小尺寸(如,2KB)的远程过程调用效率更高。在这类邮件网络内改进性能的一种已知方式是缓冲多个请求和/或应答,用于在单个远程过程调用内传输。
例如,图5示出邮件客户机组件501和邮件服务器组件502之间请求和应答的交换。邮件客户机组件501和邮件服务器组件502各具有固定尺寸的通信缓冲区503、504、505和506。缓冲区503、504、505和506是临时保持数据的存储保留区域。邮件客户机组件501通过在把缓冲区503的内容发送到缓冲区504之前用一个或多个子请求或远程操作(ROP)来填充缓冲区503,从而开始请求-应答周期。
在ROP被缓冲区504接收之后,处理各ROP,以便通过邮件服务器组件502把相应的结果写入缓冲区505。各ROP确实产生某些结果。结果可能包括邮件客户机组件501所请求的数据,例如,一组特定的邮件信息。邮件服务器组件502监控缓冲区505,当它近乎满(如,剩余部分小于8KB)时,邮件服务器组件502就把任何未经处理的ROP写入缓冲区505末端,并且把缓冲区505发送至缓冲区506。然后,当缓冲区503再次变满时,邮件客户机组件501通过把未经处理的ROP写入缓冲区503用于再次提交给邮件服务器组件502,从而开始新的请求-应答周期。
应答的尺寸一般平均比请求的尺寸大。为此,应答缓冲区505和506的尺寸一般被配置成比请求缓冲区503和504的尺寸大。在本发明一实施例中,对于尺寸为32KB的请求缓冲区503和504,应答缓冲区505和506的最佳尺寸被确定为96KB,比率为1比3。在一实施例中,邮件客户机组件能够配置任一缓冲区503、504、505和506的尺寸。
使用缓冲区的某些邮件网络,例如图5所示的邮件网络,可以采用邮件客户机组件和邮件服务器组件之间的快速传送模式。快速传送模式包括客户机的请求,譬如ROP,它们被分成至少两种:导致服务器处快速传送数据源的初始化的请求,以及导致数据从快速传送数据源到客户机的有效传输的请求。例如,快速传送数据源可以是数据库表格。快速传送数据源充当数据的就绪临时存储,它能用较低延时来服务稍后对数据的请求。有时,第二种快速传送模式请求设法通过显式地指定应答尺寸而实现有效的数据传送,例如,可以把应答尺寸设为整个客户机接收缓冲区减去应答开销的尺寸。
图6A示出具有至少两个请求-应答周期的快速传送操作。在第一请求601中,ROP(如,FXPrepare)初始化服务器502上的快速传送数据源。在服务器处,仅处理FXPrepare(即,初始化快速传送数据源),并且在第一应答602内返回其结果。在第二请求603中,ROP(如,FXGetBuffer)请求服务器从快速数据源填充缓冲区505。服务器把快速数据源排空至缓冲区,并且在第二应答604内返回结果。如果邮件服务器组件的输出缓冲区505在排空快速数据源之前填满,则可能需要附加的FXGetBuffer ROP。
图6B示出仅有单个请求-应答周期的快速传送操作。在第一请求605中,邮件服务器组件502处理FXPrepare和FXGetBuffer两者,两个操作的结果都在第一应答606内返回。由于每个缓冲区503、504、505和506的一部分显式地被定义为共享数据表,因此FXPrepare的结果可用于邮件服务器组件502处的FXGetBuffer。希望减少请求-应答周期数,因为这会导致更有效的数据传送。当缓冲区505太满而不能保持FXGetBuffer ROP的结果时,可能出现具有不止单个请求-应答周期的快速传送操作。
可以理解,图6A和6B及本申请中类似附图的ROP都是示意性的,因为它们在实践中可以用一连串ROP来实现,除非特别指出。
一般而言,ROP结果的尺寸不同于ROP请求的尺寸。并不总是能预测ROP结果的尺寸。当数据压缩技术用于减少ROP结果的尺寸时,更难预测ROP结果的尺寸。不能预测ROP结果的尺寸会防止手工调谐协议而使为完成特定客户机操作所需的请求-应答周期数最小,例如,为了确保所有新的信息都在单个请求-应答周期内被下载至客户机。手工调谐协议包括手工配置协议请求、应答和/或ROP的顺序和/或尺寸。
按照本发明一方面,通过指明不需要关键ROP(如,FXGetBuffer)来预测它们结果的尺寸,从而自动地使请求-应答周期数最小。然而,这类ROP被邮件服务器组件502处理,直到达到缓冲区505(与缓冲区506相同)的界限为止。
例如,在包括多个版本邮件服务器组件的环境中,可以为在前版本的服务器组件和最新版本的服务器组件定义分开的ROP。不需要最新版本来预测它们结果的尺寸。这些ROP的特性在下表中列出:
|
可由协议用来与在前版本服务器通信的ROP |
可由协议用来与最新版本服务器通信的ROP |
ROP ID |
FXGetBuffer |
FXGetBuffer |
多种模式中所用的参数 | 所需尺寸:服务器必需保留在其输出缓冲区内的尺寸 | 所需尺寸:被设为在前版本预期的最大值之上,例如,被设为大于32KB的值。这通知服务器查找新的尺寸界限参数 |
新参数 |
n/a | 尺寸界限:通知服务器把界限提高到服务器可填充其输出缓冲区的界限。 |
在前版本服务器组件的ROP在结构上与现有技术ROP相似。也就是,ROP预测并规定输出缓冲区(如,发送缓冲区505)内必需保留用于保持应答的尺寸。相反,最新版本服务器的输出缓冲区所规定的尺寸不被预测,而是被设为在前版本服务器组件所预期的最大值之上,例如,被设为大于32KB的值。输出缓冲区的尺寸被定义为高于服务器组件所预期的值会使服务器组件查找新的尺寸界限参数,该参数可以是如服务器组件输出缓冲区的填充。这些特性自动地使请求-应答周期数最小,并且仅仅略微增加了处理ROP的邮件服务器组件的复杂度。
注意到上表及本申请中类似表格中示出的参数顺序不必要与参数在网络上发送的顺序或者被邮件客户机组件或邮件服务器组件存储在内存中的顺序相关,除非特别指出。此外,为了简洁可以省略未变化的参数。
在邮件网络中,协议的一般目的之一是实现数据对象的传输,例如,邮件客户机组件和邮件服务器组件之间的邮件信息。这类数据对象的进一步示例包括可能包含邮件信息和其它数据对象的邮件文件夹,以及文件夹相关信息(FAI)数据对象,例如,后者可能包含用于处理邮件信息的规则,或者定义将怎样显示文件夹所包含的数据对象。数据对象对于邮件客户机组件可能是不透明的;即,邮件客户机组件可能无法解释数据对象的内容。或者,数据对象可能由命名的(named)属性组成,例如,邮件信息可能包括被命名为“到(to)”、“自(from)”、“主题(subject)”、“重要性(importance)”、“正文(body)1”、“正文2”、“正文3”、“附件(attachment)1”、“附件2”等等的属性。
邮件网络的一个好处在于能潜在地改进协议性能,这是因为协议能仅传送部分数据对象,其中邮件网络中,数据对象可能包括数据对象不透明处的邮件网络上的命名属性。具有命名属性允许发送数据对象的特定属性,而不发送整个数据对象。
例如,邮件信息可能包括一组头部属性和一组正文属性。邮件客户机组件的需求可以是协议首先传送头部属性,然而传送正文属性或者根本不传送。该特性允许用户在完全下载所有信息前查看几个信息的头部信息。通过使用该特性,客户机组件可以获得对带宽利用率更精细的控制,这会正面影响协议性能。此外,客户机可以用该特性来导致较低的带宽利用率(例如,可能仅为所选头部下载正文),这尤其在低带宽环境中是理想的。
如果服务器组件被配置成在两个分开的请求-应答周期(即,头部和正文各用一个周期)中发送正文和头部属性,则不必要增加协议的性能。例如,如果邮件客户机组件的需求是同时要求头部和正文属性,则在单个请求-应答周期可检取头部和正文的情况下,协议性能可能下降。因此,简单地使数据对象包括命名属性不足以自动地导致改进的协议性能。达到改进的协议性能取决于组成数据对象的属性的选择,以及它们怎样被协议所使用。该选择可能取决于许多因素,包括对最新和在前版本邮件客户机组件的需求、以及对最新和在前版本邮件服务器组件的需求。邮件客户机组件需求的示例包括满足用于显示不同信息的不同紧急级别、以及符合邮件客户机组件用户所设定的首选项。邮件服务器组件需求的示例包括数据的有效存储和检取、以及协议请求的有效处理。
常规的现有技术邮件环境使用可由命名属性组成的数据对象,例如,可能包括命名属性的头部组和正文组的邮件信息,从而可以分开地请求并/或处理这两个组。另一现有技术示例是一邮件信息,其中正文命名属性组包括多个版本的邮件信息正文,例如,以像纯文本、超文本链接标识语言(HTML)、多信息文本格式(RTF)等多种邮件信息格式。在这种情况下,现有技术邮件服务器组件可能以多种方式对邮件信息正文的协议请求进行应答。最低复杂度的应答可能是发送所有版本的邮件信息正文,但该应答可能导致增加的带宽使用率。
图7A描述了在前(现有技术)版本邮件服务器组件用于在该情况下应答的部分过程。步骤701中,邮件服务器组件检查每个邮件信息正文的格式。如果这些格式之一是预定的标准格式(如,RTF),则过程移至步骤703,并且把标准格式邮件信息正文发送到正在请求的邮件客户机组件。如果没有任何格式是预定的标准格式,则步骤701分支到步骤702,其中邮件信息正文版本之一被转化成标准格式。当仅有单个邮件消息正文版本、但该邮件信息正文不是协议所要求的标准格式时,也可以使用图7A所述的子过程。
图7B描述了按照本发明由最新版本邮件服务器组件所使用的部分过程。步骤704中,检查导致该子过程被邮件服务器组件所使用的协议请求是否有BEST_BODY标志。该例中的标志及这里所用的其它标志用于邮件服务器组件,使邮件客户机组件是最新版本,并且期望实现与标志相关的功能。也可以使用其它指示。例如,如果检测到最新邮件客户机组件,则可以缺省地实现该功能。
任何情况下,如果未找到BEST_BODY标志,则步骤704分支到步骤701,并且参照图7A所述继续。
如果找到标志,过程移动到步骤705,其中选择最佳邮件信息正文,用于发送至正在请求的邮件客户机组件。如果仅有单个邮件信息正文与所请求的邮件信息相关,则是最佳的。如果有几个邮件信息正文可用,例如,有不同格式,则邮件服务器组件按照如邮件信息正文格式(如,RTF、HTML、纯文本)的预定排列而从中选择最佳的。然后,过程进行到步骤703,其中把所选的邮件信息正文发送到邮件客户机组件。在该实施例中,邮件客户机组件也许能够显示多种邮件信息正文格式,从而使邮件服务器组件无须把邮件信息正文转化成标准格式。此外,邮件客户机组件可以根据需要把最佳的邮件信息正文转化成不同的格式。
由于减轻了邮件服务器组件转化信息正文的任务,因此本发明提供了改进的性能。此外,最新版本邮件服务器组件可能对来自在前版本邮件客户机组件的协议请求进行应答,而仅适度地增加复杂度。
ROP可能用于实现邮件服务器组件和邮件客户机组件间邮件文件夹的复制。例如,SynchFolder Rop可能作出同步文件夹的请求。在邮件客户机组件能够显示非标准邮件信息正文格式之处,它可以在SynchFolder ROP内设置BEST_BODY标志来指名邮件服务器组件可以从可用的邮件信息正文中选择最佳格式,而不是要求服务器返回标准格式的邮件信息正文。邮件服务器组件可以适当地处理具有或者没有BEST_BODY标志的ROP,而仅适度地增加复杂度。用来与在前版本和最新版本服务器进行通信的ROP可能包括,例如,下表中提出的特性:
|
由协议用来与在前版本服务器通信的ROP |
由协议用来与最新版本服务器进行通信的ROP |
ROP ID |
SynchFolder |
SynchFolder |
新参数 |
n/a | BEST BODY标志:如果被设定,邮件服务器组件就选择最佳邮件信息正文发送到邮件客户机组件。邮件信息正文到预定标准格式的转化是不必要的。 |
图8A-8C示出用于在邮件服务器组件和邮件客户机组件间传递一组邮件信息的几种不同的现有模式。对于每个模式而言,每个邮件信息都有包括头部组和正文组在内的命名属性,且几个邮件信息被包含在一文件夹中。图8A说明了完整条目传送模式。该说明示出被传送的第一邮件信息头部801,然后是第二邮件信息头部803前的第一邮件信息正文802,然后是第二邮件信息正文804,依此类推,直到已经传送了该组邮件信息为止。图8B说明了一头部优先传送模式。该模式中,先传送第一邮件信息头部805,然后是第二邮件信息头部806,依此类推,直到传送了所有邮件信息头部为止,只有这时才传送第一邮件信息正文807,然后是第二邮件信息正文808,依此类推,直到传送了该组邮件信息为止。图8C说明了仅有头部的传送模式。如名字里所指明的,响应对传送一组邮件信息的请求,仅传送邮件信息头部809。邮件信息正文810仅响应附加的显式请求而被传送。在任一这些模式中,传送顺序可能被较高优先级的邮件客户机组件请求所临时打断,例如,为了特定的邮件信息正文。
邮件文件夹是请求传送一组邮件信息的目标的示例。然而,邮件文件夹可能包含除邮件信息之外的数据对象。如上所述,通常参照邮件信息头部和邮件信息正文而定义传送模式,譬如头部优先和仅有头部的传送模式。在这些模式中,如果没有为数据对象很好地定义命名属性的头部组和/或命名属性的正文组,则传输这些数据对象的企图可能导致协议故障。本发明一方面通过总之总体而非部分地传输未很好定义命名属性的头部和/或正文组的数据对象而避免了该情况。该实施例可以用图8D的示例来说明。该例中,邮件服务器组件和邮件客户机组件间的传送可能发生在仅有头部的模式。因而,传送第一邮件信息头部811,然后数据对象812成为下一候选传送物。没有为数据对象812很好地定义命名属性的头部组,譬如为FAI,因此传送整个数据对象。下一候选传送物具有很好定义的命名属性的头部组(即,候选数据对象确实处理被邮件客户机组件显式定义为属于命名属性头部组的所有命名属性),因此仅传送邮件信息头部813。
实现本发明这方面的一种示例方式是通过使用一标志,譬如IGNORE_MDE_ON_FAI,它可以包括在同步ROP内,譬如上述SynchFolder ROP。邮件服务器组件可以适当地处理有或没有IGNORE_MODE_ON_FAI标志的ROP,而仅适度地增加复杂度。ROP可能包括下表内提出的特性,用于实现邮件服务器组件和邮件客户机组件间邮件文件夹的复制:
|
由协议用来与在前版本服务器通信的ROP |
由协议用来与最新版本服务器进行通信的ROP |
ROP ID |
SynchFolder |
SynchFolder |
新参数 |
n/a | IGNORE MODE ON FAI标志:如果被设定,则对于不具有很好定义的命名属性的头部组和/或正文组的数据对象而言,譬如FAI,邮件服务器组件可能用整个数据对象对传送请求应答,而不考虑主要传送模式。 |
邮件信息一般被定址到一个或多个邮件网络用户。如果邮件信息被邮件服务器组件接收到用于存储,则它被视作已传递。邮件网络可能有几个邮件服务器组件。一般而言,邮件网络协议具有限制邮件服务器组件数目使邮件网络用户必需检查新信息的某些策略。通常示例是本地服务器策略,它使定址到特定邮件网络用户的邮件信息仅被一个特定邮件服务器组件所接受,该组件称为用户的本地服务器。这种情况下,邮件客户机组件可被配置成当周期性检查新的邮件信息或者为注册新到邮件通知时,仅考虑本地服务器。
图9示出即使简单的本地服务器策略示例也可能有其复杂性。在图9所述的示例中,首先把特定的邮件服务器组件901指定为特定邮件网络用户的本地服务器。随着时间的推移,为用户指定的本地服务器变成不同的邮件服务器组件903和905,一般为了管理原因。例如,邮件服务器组件901、903和905可以是物理上不同的、或逻辑上不同的、或者为不同版本。邮件客户机组件902在时刻T0到时刻T1可能仅与邮件服务器组件901通信,接着邮件客户机组件904在时刻T2前可能仅与邮件服务器组件903通信,然后邮件客户机组件906可能仅与邮件服务器组件905通信。邮件客户机组件902、904和906可以相同或不同。邮件服务器组件901和903在时刻T2后可能存在或可能不存在。这些复杂性尤其与下面讨论的邮件信息存储复制有关。
邮件信息可以被显式邮件信息存储内的邮件服务器组件所存储,后者可以用如公知的数据库技术来实现。邮件服务器组件可能有一个或多个这样的信息存储。邮件网络用户可能有一本地信息存储。改变本地信息存储会有与改变本地服务器一样的效应。
某些邮件网络协议能够把邮件信息存储的一部分复制到邮件客户机组件本地的存储设备中。把部分远程邮件信息存储复制到本地邮件存储设备可以通过在显式邮件网络用户请求观察新邮件前把所有新邮件信息复制到本地邮件存储设备,从而改进协议性能和/或所观察的协议性能。这种复制还能提供附加的邮件客户机组件功能,例如,使邮件网络用户能在网络连接中断期间查阅邮件信息。
在邮件网络环境中,简单的复制可能迅速变得效率低下。例如,如果邮件服务器组件具有与特定邮件网络用户相关的一邮件信息,且该信息已经在网络用户的客户机组件处被复制,而且新的邮件信息抵达该邮件网络用户,那么仍旧要求响应简单复制请求而发送两个邮件信息。如果另一新邮件信息在复制了两个邮件信息后抵达,那么仍旧要求响应简单复制请求发送三个邮件信息,依此类推。为了减轻这个问题,某些邮件网络协议已经提供了对邮件信息存储的增量复制。在增量复制中,响应复制请求仅发出在前成功增量复制后发生的邮件信息存储的变化,例如,当自上一次成功增量复制以来的仅有变化是新邮件信息的抵达时,响应增量复制请求仅需发出该新邮件信息。
图10示出提供了增量复制的协议的更详细的示例。邮件信息存储可以再被分成邮件文件夹。每个邮件文件夹都可以独立于其它而被复制,提供对复制进程的更精确的控制。该例中,由于增量复制进程包括把变化从邮件客户机组件501传播至邮件服务器组件502,以及从邮件服务器组件502传播至邮件客户机组件501,因此增量复制进程被称为同步。同步请求1001之后,邮件服务器组件502处理SynchFolder ROP。所述ROP包括folderID参数(未示出)和stateblob0参数。FolderID参数标识了作为同步请求1001的目标的邮件文件夹。Stateblob0参数包含允许邮件服务器组件502确定自邮件文件夹上一次同步以来对其发生的变化的信息。如果请求1001用邮件客户机组件501代表目标文件夹的第一同步请求,则邮件服务器组件502确定与空文件夹相比,邮件信息存储内的目标邮件文件夹是否已变化。在对请求1001的应答1002中,邮件服务器组件502发出对邮件客户机组件501的任何变化,包括已经被添加到目标文件夹的任何邮件信息和/或其它数据对象、以及已经从目标文件夹删除的任何邮件信息和/或其它数据对象列表。邮件服务器组件502还创建了新的stateblob1,表示同步后立即在邮件客户机组件501上的目标文件夹的状态,并且还在应答1002内发送该stateblob1。当邮件客户机组件501对与请求1001内相同文件夹的下一同步请求1003时,请求1003会包括与应答1002所返回的相同stateblob1参数。像以前一样,邮件服务器组件502会用包含在stateblob1内的信息来确定目标文件夹内是否发生任何变化,并且在应答1004内把那些变化与新创建的stateblob2一起发回邮件客户机组件501。
如果状态块数据对象的尺寸很大,它就会有害地影响协议性能,这是因为它根据每个邮件文件夹同步请求被发送到邮件服务器组件或从中被发回。在提供邮件文件夹同步的某些邮件网络协议中,状态块很大部分由一组信息changeID(变化标识)数据对象组成,它们表示邮件客户机组件所见的对邮件信息的变化。邮件信息变化可以在改变后的邮件信息被传送至邮件客户机和/或服务器组件时而被该组件所见。
信息changeID数据对象的一个目标是在整个邮件网络环境中唯一地标识对邮件信息的变化。在采用本地服务器策略的邮件网络中,用户的本地服务器可能负责把信息changeID数据对象与在前未见到的邮件信息变化相关联。例如,本地服务器可以采用由serverID(服务器标识)数据对象和序列号组成的信息changeID数据对象。ServerID数据对象可以用像全局唯一标识符这样的公知技术在整个邮件网络环境中唯一地标识邮件服务器组件。在这种标识符自身尺寸很大时,serverID数据对象反而可以是由邮件服务器组件所维护的标识符查找表内的索引。序列号可以由邮件服务器组件本地的计数器来提供,例如,宽度为六字节的计数器,计数器在邮件服务器组件接受在前未见到的邮件信息用于存储时递增。
为了讨论目的,信息changeID数据对象可以用“S1:1”表示,其中“S1”表示第一邮件服务器组件的serverID数据对象,而“1”表示序列号。一组信息changeID数据对象可以用“S1:1,S1:2,S1:3”表示,其中“S1:1”、“S1:2”和“S1:3”是由具有serverID S1的邮件服务器组件所采用的连续信息changeID数据对象。
当状态块很大部分由一组信息changeID数据对象组成时,其中这组数据对象表示邮件客户机组件所见的邮件信息变化(“信息变化已见(Message ChangesSeen)”组),那么为了降低其尺寸而开发了某些技术来对该组编码,例如,组“S1:1,S1:2,S1:3,S1:4”可以被编码为“S1:1-4”。此外,邮件服务器组件可以确保它使用的序列号总是在递增。在该情况下,像“S1:1,S1:3,S1:5,S1:7”这样不连续的信息变化已见组可以被编码为“S1:1-7”,也就是,被编码为包括最小和最大序列号的范围,而不丧失功能。
在图9所示的场景中,信息变化已见组可以包括由除当前本地服务器(如,S
3)之外的邮件服务器组件(如,S
1,S
2)所创建的信息changeID数据对象。由当前本地服务器所创建的信息changeID数据对象可以被称为本地(native)信息changeID,由其它邮件服务器组件所创建的信息changeID数据对象可以被称为外来信息changeID。与在前版本邮件服务器组件通信的邮件网络协议没有按每个邮件服务器组件逐一地把不连续的外来信息changeID序列优化成包括最小和最大序列号的范围。下表说明了把这种优化包括在本发明实施例中的好处:
|
由在前版本服务器所使用的优化(当前本地服务器S3) |
由最新版本服务器所使用的优化(当前本地服务器S3) |
优化前的信息变化已见组 |
S1:1,S1:3,S1:5,S1:7S2:1,S2:3,S2:5,S2:7S3:1,S3:3,S3:5,S3:7 |
|
由在前版本服务器所使用的优化(当前本地服务器S3) |
由最新版本服务器所使用的优化(当前本地服务器S3) |
优化后的信息变化已见组 |
S1:1,S1:3,S1:5,S1:7S2:1,S2:3,S2:5,S2:7S3:1-7 |
S1:1-7S2:1-7S3:1-7 |
本发明一实施例使用包括下表所列特性的ROP来实现邮件服务器组件和邮件客户机组件间邮件文件夹的同步。邮件服务器组件可以实现改进的状态块编码技术,而仅适度地增加复杂度。
|
与在前版本服务器通信时由协议所使用的ROP结果 |
与最新版本服务器通信时由协议所使用的ROP结果 |
ROP ID |
SynchFolder |
SynchFolder |
新模式内使用的未变化的参数 | 状态块:不包括外来信息changeID数据对象的不连续组的优化 | 状态块:包括外来信息changeID数据对象的不连续组的改进了的优化 |
图11A和图11B描述了分别由在前版本服务器和最新版本服务器用来应答SynchFolder ROP的子过程之间的差异。图11A示出步骤1101、1102和1103。步骤1101中,构建初始信息变化已见组。步骤1102中,优化信息是本地信息changeID数据对象的信息变化已见组的成员。步骤1103中,经优化的信息变化已见组被添加到状态块数据对象,后者与应答一起发送到请求同步的邮件客户机组件。图11B包括附加步骤1104,其中示出的是外来信息changeID数据对象的信息变化已见组的成员,它们在信息变化已见组在步骤1103中被添加到状态块数据对象之前也被优化,现在具有改进的优化。
尽管把邮件信息存储再分成邮件文件夹确实提供了对同步进程更精确的控制,然而它不能自动改进协议性能,并且可能导致协议性能的降级。例如,某些协议要求分开地同步每个信息存储文件夹。每个同步操作一般有某些开销,该开销可能是巨大的。使用状态块数据对象的同步操作是具有显著开销的操作示例。在同步整个信息存储的情况下,相比要求较少同步操作的协议而言,要求分开同步每个信息存储文件夹的协议可能是不利的。
同步整个信息存储并且维持同步是邮件客户机组件的期望目标。常规的现有技术邮件客户机组件即使在它导致对协议性能的显著负面影响时,也设法实现该目标。本发明一方面是它能使有害协议影响最小的同时,通过使用深层次表来实现该目标。常规的现有技术邮件服务器组件尚不能提供深层次表。
当邮件信息存储再被分成邮件文件夹时,那些邮件文件夹可以被组织成层次。图12示出邮件文件夹层次的示例。图12中,文件夹1204是文件夹1203的子文件夹。文件夹1203又是文件夹1202的子文件夹。文件夹1201是根文件夹。根文件夹不是任何其它文件夹的子文件夹。所有其它文件夹都是以文件夹1201为根的文件夹层次的成员。一般而言,文件夹层次中的每个文件夹都不直接引用各个其它文件夹。文件夹可能仅能直接引用其子文件夹。文件夹还能直接引用以它为子文件夹的任何文件夹。在许多情况下,每个文件夹能直接引用的可能仅是层次的根文件夹。
深层次表可能包含关于文件夹层次中每个文件夹的信息。每个文件夹在深层次表中可能有一行。深层次表中的信息使它能用来确定邮件文件夹的内容在特定时间段内是否变化。可以用时间段开始处文件夹行的拷贝与时间段结束处文件夹行的拷贝的简单比较,来确定特定时间段内对邮件文件夹的变化。一实施例中,深层次表的每行都包括下列属性:
属性名 |
属性类型 |
注解 |
Folder ID |
FID |
FID类型包括一全局唯一标识符(GUID)和一六字节序列号。该值可以用于在邮件网络环境中唯一地标识邮件文件夹。 |
PR_LOCAL_COMMITT_IME_MAX |
Timestamp(时标) |
该时标在修改文件夹内容之时被更新 |
PR_DELETED_COUNT_TOTAL |
QWORD |
该值是从文件夹被删除的条目总数的计数 |
深层次表内邮件文件夹行的属性可以在对文件夹内容作出变化时被更新。为了有效地实现深层次表更新,申请人发现,快速并直接引用深层次表是有帮助的。至少,申请人发现,在试图访问深层次表时,应该有小并且可预测的间接层数。例如,把深层次表定位在文件夹层次中的任意层次不会提供可预测的间接层数。为此,在本发明一实施例中,深层次表可能与邮件网络用户的邮件信息存储文件夹层次的根文件夹相关联。
邮件客户机组件和邮件服务器组件间的通信可被分成多个通信会话。会话间可能发生邮件信息存储同步的丢失,例如,在网络连接中断期间。为了在通信会话开始处重建邮件信息存储同步,用于与在前版本邮件服务器组件通信的某些协议为文件夹层次中的每个文件夹采用了SynchFolder ROP。一般而言,某些文件夹的内容不会在会话间发生变化。用未变化的文件夹作为其目标的SynchFolder ROP导致“零同步”(null synch)。尽管“零同步”不导致任何文件夹变化被传送到邮件客户机组件,然而它仍有与其相关的开销,例如,状态块数据对象,它可能是显著的。
图13说明了通过使用深层次表来避免这种“零同步”结果的本发明一实施例。在第一请求1301中,邮件客户机组件501把请求深层次表的ROP(如,GetHierarchyTable)发送至邮件服务器组件502。在第一应答1302中,向邮件客户机组件501提供深层次表的拷贝。一般而言,邮件客户机组件501会有深层次表的在前拷贝。邮件客户机组件501可以通过使用两个拷贝的逐行比较,从而迅速确定邮件服务器组件502上用户的邮件信息存储内的哪些文件夹已变化。接着,采用ROP(如,SynchFolder)来仅仅同步那些发生变化的文件夹。根据需要可以重复请求1303和应答1304来同步经变化的文件夹。成功同步之后,可以更新深层次表的邮件客户机组件的拷贝,使之与应答1302中发送的最近的拷贝相匹配。如果邮件客户机组件501没有深层次表的在前拷贝,那么可能同步具有最新拷贝内一行的所有文件夹。
一旦已经建立了用户邮件信息存储的同步,则可以通过周期性地重复上述会话起始步骤(即,轮询邮件服务器组件)而维持同步,但该方案是不利的。例如,轮询周期可能大大短于用户邮件信息存储发生变化之间的时间段。这样,相对而言许多深层次表比较会表明没有文件夹发生变化。这种比较实际上是浪费的,因此能避免它们的协议会更有效。
某些邮件网络包括使得邮件客户机组件预订在特定邮件文件夹的内容发生变化时被邮件服务器组件通知到的设备。某些在前版本邮件客户机组件通过为与用户文件夹层次内每个相关的变化通知创建分开的预订,而确实使用了这种设备来维持用户邮件信息存储的同步。在本发明一实施例中,邮件客户机组件可以为与深层次表相关的变化通知仅创建单个预订。单个预订更有效,因为需要较少的ROP来建立它,并且消耗较少的服务器端资源。
进一步参照图13,按照本发明一方面,当最新版本的邮件客户机组件501在与邮件服务器组件502的通信会话开始处在第一请求1301内采用GetHierarchyTable ROP时,邮件客户机组件501自动预订与深层次表相关的变化通知,它在应答1302中返回。当邮件客户机组件处的用户邮件信息存储内的邮件文件夹发生变化时,例如,向文件夹添加一邮件信息,则如前所述地更新深层次表。对深层次表的变化触发一通知报警1305到邮件客户机组件501。虽然通知报警响应了请求1301所做的预订,然而它不是显式请求-应答周期的一部分。因此,本发明所提供的通知系统的使用大大减少了邮件网络的开销。
单个预订可能导致许多通知。一实施例中,使用无连接(connectionless)网络传送机制来传递报警,例如,使用用户数据报协议/因特网协议(UDP/IP),但是也可以使用任何适当的网络传送机制。响应报警,邮件客户机组件501把包含ROP(如,GetNotification)的请求1306发送到邮件服务器组件502。在应答1307中,把深层次表的任何变化了的行(即,与触发通知的已变化文件夹相对应的行)发送到邮件客户机组件501。然后,邮件客户机组件501采用ROP(如,SynchFolder)来仅仅同步已变化的文件夹。
可以为与同一数据对象(如,同一邮件文件夹)相关的变化通知预订多个邮件客户机组件,例如,以提供合作功能。如图18所示,为了与邮件服务器组件1804上的同一数据对象(未示出)相关的变化通知预订了邮件客户机组件1801、1802和1803。邮件客户机组件1803把ROP 1805发送到邮件服务器组件1804,导致数据对象变化。变化结果是,邮件服务器组件1804发出变化通知1806、1807和1808到邮件客户机组件1801、1802和1803。变化通知可能携带不能标识已变化的数据对象的极少信息,使得邮件客户机组件也许不能确定它是变化的缘由。如果数据对象是邮件文件夹,则变化通知1806、1807和1808可能导致各邮件客户机组件1801、1802和1803为已变化的文件夹开始同步。由于该例中邮件客户机组件1803对变化负责,因此结果会是“零同步”。
为了前面所讨论的原因,可能希望消除导致“零同步”的同步。然而,所述通知行为不总是不理想的,某些邮件客户机组件可能依赖于它。本发明一方面是使邮件客户机组件能配置最新版本邮件服务器组件的通知行为,以便改进协议性能,与此同时向在前版本邮件客户机组件提供未变化的通知行为。
图19A描述了可能由在前版本邮件服务器组件所提供的通知行为。图19B描述了按照本发明一方面的可配置通知行为。根据需要,最新邮件客户机组件可能表示能进行图19B的通知行为的邮件服务器组件,例如,通过与请求一起提供一标志,在图19B所示的示例中是IGNORE_OWN标志。
步骤1901中,选择要被通知的订户组中的下一候选者。步骤1904中,检查预订是否有IGNORE_OWN标志。如果标志不存在,则步骤1904分支到步骤1902,其中把通知发送到候选订户。如果找到标志,则步骤1904分支到步骤1905,其中再次检查预订以确定订户是否曾触发该通知。该确定可以通过检查用于放置预订的会话的通信会话标识符(“会话ID”)来作出。例如,会话ID可以包括一全局唯一标识符和一六字节序列号。也为与其缘由相关的会话ID检查是否有通知。如果两者匹配,则消除通知。结果是引起通知的邮件客户机组件也不会接收该通知。然后,子过程进行到步骤1903,如下所述。
如果订户未触发通知,则与预订相关的会话ID不会和与通知缘由相关的会话ID相同,步骤1905分支到步骤1902,其中发送通知。然后,过程进行到步骤1903,其中确定是否要通知更多订户。如果是,则子过程返回到步骤1901,否则该子过程结束。
如上所述,使用邮件信息的高速缓存的邮件客户机组件可能通过如ROP来请求本地客户机数据存储和邮件服务器处可用的数据存储之间、信息或其它数据对象的同步。邮件客户机组件可能类似地请求从服务器存储把信息拷贝到客户机存储。在任一情况下,可以用快速传送模式作出请求。
一般而言,当为同步或拷贝而请求信息或像文件这样的其它数据时,请求(如,ROP)包括对希望同步的所有信息的指示。该列表可以由邮件服务器组件自动构建,例如,通过使用上述状态块特征。对于在前版本(现有技术)的邮件服务器组件而言,ROP请求中的一个信息或数据对象内的错误会导致请求内所有条目的故障。该过程在图14A示出,其中在步骤1401发送包含ROP的请求(如,FXPrepare),而为拷贝或同步指定messageID(信息标识)组。在邮件服务器组件502处建立快速传送机制,并且在步骤1402把快速传送ID发送至邮件客户机组件501。然后,邮件客户机组件501通过包含如FXGetBuffer ROP的请求来请求数据对象的拷贝或同步(步骤1403)。当邮件服务器组件502试图打开所请求的信息时,一个或多个信息或其它数据对象发生错误。错误的示例包括:被破坏的信息或数据对象、服务器故障、邮件服务器组件502存储溢出、或者为数据对象检测到的病毒。
在错误之后,在步骤1404中,邮件服务器组件502在到邮件客户机组件501的数据流中发送一致命的ROP错误。这样,同步失败,messageID组内的信息未被同步或拷贝,状态块或类似更新信息未被邮件客户机组件501所接收。然后,邮件客户机组件501需要在另一时刻请求数据对象的同步或拷贝。可能的是,如果错误并不固定在邮件服务器组件502处,错误信息可能继续被发送,且messageID组内的信息永远不被同步或拷贝。
按照本发明一方面,取代致命ROP错误的是,最新邮件服务器组件可能发送与特定数据对象(如,邮件信息)有关的错误信息,使仅仅该数据对象的同步失败。该特性允许即使应答内包括带有错误的信息或其它数据对象,也能发送并同步或者拷贝ROP内的信息或其它数据对象、或者其它请求。
作为怎样处理对象特定错误的一例,最新邮件服务器组件可能在具有对象错误的数据对象的数据流中发送错误信息。该例中,为了引用的方便,错误被称为FXErrorInfo。如下进一步所述,根据需要,FXErrorInfo可能包括如下信息:具有错误的数据对象的信息ID、以及关于信息为何失败的附加信息。
图14B示出一同步,其中错误发生在信息M3内。该错误导致FXGetBuffer应答1405包括信息M1和信息M2、其后是FXErrorInfo、然后是M4。FXErrorInfo信息允许邮件客户机组件501得知哪个信息带有错误,并且同步应答内所有其它的信息。如果错误信息FXErrorInfo包括与错误原因有关的信息,则可由客户机组件对该信息相应地起作用,例如,通过向用户显示一错误信息。
下表示出FXErrorInfo可能采用的格式的一例:
FXErrorInfo |
属性名 |
属性类型 |
注解 |
版本 |
WORD |
该结构的版本 |
错误代码 |
DWORD | |
信息ID |
MID |
MID类型包括一全局唯一标识符(GUID)和一六字节序列号。这是引起错误的信息的信息ID。 |
... |
... |
这里可以添加零或更多属性。 |
辅助字段大小 |
ULONG |
遵照的数组大小 |
辅助字段 |
BYTE array(字节数组) |
用于传递错误细节的无结构数组 |
如上所示,示例格式包括版本属性、错误代码和信息ID。此外,根据需要,可以添加一个或多个属性。而且,如上所述,可以为传送错误细节而定义一辅助字段。这样,可以为了规定错误细节的字段大小而定义一属性(如,数组),并且可以提供一字段,它可以是如用于传送错误细节的无结构数组。如上所述,可以根据需要由邮件客户机组件501来处理错误细节。
FXErrorInfo能够完成第一应答的同步,例如,导致向邮件客户机组件501提供状态块或其它信息。由于现在通过信息M4同步邮件客户机组件,因此下一对同步的请求1406可能导致应答1407在M4之后具有信息(如,M5和M6)。
为了指示邮件客户机组件501是最新版本,并且因此能处理FXErroInfo信息,可以定义一标志,例如,FXRecoverMode,它可以与请求同步或拷贝的ROP一起被发送。可以为邮件客户机组件501使用其它指示来告知邮件服务器组件502它能处理该FXErroInfo信息。
当邮件服务器组件502把一个或多个信息或其它数据对象发送到邮件客户机组件501时,可以用属性标志(如,ptag)分开或定义到邮件客户机组件的数据流。例如,一列信息可能包括每个信息的起始信息ptag和结束信息ptag。在起始和结束ptag之间可能是属性列表ptag和主题ptag,后两者可能有字符串的属性。主题ptag后面可以是主题自身。也可以包括其它属性标志。
在发送信息时出错的情况下,FXErrorInfo可以作为ptag被提供,并且可能有二进制属性,譬如由上表所定义。下面数据流的一例既包括成功信息,又包括其中出错的信息。在出错的情况下,不为该特定信息使用结束信息ptag,且ptagFXErrorInfo是该信息最后一个ptag。
ptagMessageListStart
ptagMessageStart
ptagPropList
ptagSubject [PT_STRING]
″Re:Your email″
…
ptagMessageEnd
ptagMessageStart
…
ptagFXErrorInfo [PT_BINARY]
[如表中的内容所描述]
ptagMessageStart
…
ptagMessageEnd
ptagMessageListEnd
图15A示出邮件服务器组件502用来把信息传送到在前版本邮件客户机组件501的步骤。从步骤1501开始,例如,通过把信息组放在快速传送数据存储中而准备信息组。步骤1502中,信息开始流出,例如在被放置在邮件服务器组件502的发送缓冲区内后立即开始。如果当流出信息时出错,则步骤1504中,致命的ROP错误流出到邮件客户机组件501。于是子过程结束。如果,当流出信息时未出错,则在步骤1503中,确定是否有更多信息在组中。如果是,则过程循环回到步骤1502,其中流出下一信息。如果否,则子过程结束。
图15B示出最新版本的邮件服务器组件502处理信息组的过程。所采取的步骤根据邮件客户机组件是最新版本或是在前版本而不同。步骤1501-1504是在前版本邮件客户机组件所采用的步骤,它们与前面段落中具有相同标号的步骤相同。
如果步骤1502中在流出信息时出错,则在步骤1505确定请求是否包括一标志,譬如FXRecoverMode。如果请求包含该标志,则邮件客户机组件501是最新版本,且步骤1505分支到步骤1506,其中FXErrorInfo流出到邮件客户机组件501。然后,进程继续到步骤1503。如果请求不包括该标志,则步骤1505分支到步骤1504,其中流出致命的ROP错误。于是子过程结束。
如图所示,请求内存在的标志通过允许流出FXErroInfo而非失败并发送指名ROP错误,从而允许流出进程继续。标志被最新版本的邮件客户机组件501发出。在前版本的邮件客户机组件不包括该标志,从而如上所述,错误导致流出致命的ROP错误。
根据需要,在另一实施例中,可以为了信息或其它数据对象的特定属性、而非为了整个信息发出错误信息(如,FXErrorInfo)。例如,可以为信息正文发出FXErrorInfo,或者为信息的附件发出FXErrorInfo。然后,邮件客户机组件501可以同步或拷贝被无错地成功发出的属性,只有有错的属性才不被同步或拷贝。
有时,信息或其它数据对象可能有足够大小从而能跨越多个FXGetBuffer应答。为了处理这类信息,邮件客户机组件501可能包括重新运行逻辑,使得它能处理任何部分接收到的信息,然后在接收错误信息后继续适当地接收进一步信息。
时常可能希望向邮件客户机组件提供与数据对象(如,邮件信息)的拷贝或同步进度有关的反馈。按照本发明一方面,最新版本的邮件客户机组件501可能指示它能处理进度模式,例如,通过在请求数据对象的同步或拷贝时,把像PROGRESS_MODE这样的标志发送到邮件服务器组件502。作为应答,最新版本的邮件服务器组件502可能与信息一起发出多种信息,譬如所有信息的总大小、信息总数、以及每个信息的总大小、或者它们的任意组合。
例如,如图16A所示,对于在前版本的邮件客户机组件501而言,邮件客户机组件501响应对一组信息的快速传送请求(1601和1603)而接收这些信息。图16A中,在两个应答1604和1606内接收信息。在使用快速传送机制的在前版本邮件客户机组件501中,不提供对流出到客户机的信息的进度指示。
然而,如图16B所示,响应对邮件客户机组件的信息组的应答1607,邮件服务器组件502可能提供要被传送的数据对象总数、以及要被传送的所有数据对象的总大小。该信息在图16B中用“Pall”表示。最新版本的邮件服务器组件502也可能提供每个信息的大小,在图16B中用“P1、P2、P3、...”表示。此外,根据需要,与每个信息相关以及与整组信息相关的信息可能包括与每个信息是FAI还是实际邮件信息有关的附加信息。一实施例中,图16B中用“Pall”表示的信息总是响应快速传送请求而被发送,即使传送零数据对象时,这是为了简化数据流的处理。
下表示出被传送的所有数据对象的大小和数目的格式示例。
IncrSyncProgressMode |
属性名 |
属性类型 |
注解 |
版本 |
WORD(如,16位整数) |
该结构的版本。 |
cAssocMsgs |
DWORD(如,32位整数) |
要传送的FAI数据对象数目 |
llTotalAssocMsgSize |
QWORD(如,64位整数) |
要传送的所有FAI数据对象的总大小 |
cNormalMsgs |
DWORD |
要传送的邮件信息数目 |
llTotalNormalMsgSize |
QWORD |
要传送的所有邮件信息的总大小 |
如上所示,可以为FAI数据对象数目、所有FAI数据对象的总大小、要传送的邮件信息数目、以及要传送的所有邮件信息的总大小而定义分开的属性。根据需要也可以向格式添加其它组合和附加的属性。
下表示出可以向每个信息提供的大小及其它信息的格式。
IncreSyncProgressModePerMsg |
属性名 |
属性类型 |
注解 |
信息大小 |
LONG(长型) |
下一信息的大小 |
FAI标志 |
BOOL(布尔型) |
指示下一信息是否是FAI |
如上所示,格式包括下一信息的大小以及下一信息是否为FAI。
图17A和17B分别示出按照在前版本邮件组件和最新版本邮件组件流出信息组的步骤。图17A中的步骤类似于图15A中的步骤1501-1503。对于图17B而言,由最新邮件客户机组件501与ROP一起发出PROGRESS_MODE标志。在步骤1701处准备好信息组之后,确定是否存在该标志。如果是,则在步骤1702中发出进度数据总和,进程接着进行到步骤1502,其中流出第一信息。如果不存在该标志,则步骤1701直接分支到步骤1502。
在流出第一信息之后,进程继续到步骤1703,其中确定标志是否可用。如果是,则步骤1703分支到步骤1704,其中流出每个信息的进度数据。然后,进程继续到上述步骤1503。如果标志不可用,则步骤1703直接分支到步骤1503。
下面提出最新服务器组件的数据流示例,该组件把数据发送到最新的客户机组件。该数据流类似于上述数据流,除了包括进度总和数据的ptag(ptagIncrSyncProgressMode)以外,该ptag可以是如二进制属性。此外,对于每个信息而言,提供了每信息的进度数据,例如,ptagIncrSyncProgressModePerMsg。
PtagIncrSyncProgressMode [PT_BINARY]
[如表中的内容所描述]
ptagMessageListStart
PtagIncrSyncProgressModePerMsg [PT_BINARY]
[如表中的内容所描述]
ptagMessageStart
ptagPropList
ptagSubject [PT_STRING]
″Re:Your email″
…
ptagMessageEnd
PtagIncrSyncProgressModePerMsg [PT_BINARY]
[如表中的内容所描述]
ptagMessageStart
…
ptagMessageEnd
PtagIncrSyncProgressModePerMsg [PT_BINARY]
[如表中的内容所描述]
ptagMessageStart
…
ptagMessageEnd
ptagMessageListEnd
在所示示例中,ptag包括进度总和数据(ptagIncrSyncProgressMode),且信息进度数据的ptag(ptagIncrSyncProgressModePerMsg)位于信息列表前面,并且分别在每个信息前面。然而,可以修改流出数据对象的结构,使进度数据可以被包括在信息或信息列表内。还可以修改流出数据对象的结构,以便完全消除对信息和/或信息列表定界的ptag。
接收进度数据的邮件客户机组件可以用该数据来确定同步或拷贝来自邮件服务器组件的数据对象的进度,并且用每信息的进度数据来确定每个单独信息的进度。该信息可以是有用的,譬如,在监控与同步进度有关的实时信息时。
为了存储邮件信息或其它数据对象可能使用几种不同的字符集。例如,ASCII是存储英语字符最常使用的。然而,ASCII不足以存储所有语言的字符,由于它是基于8位字符的。因此,ASCII码仅用于256字符,它对英语是足够的,但对于具有更多字符的语言却不够。另一方面,统一字符集(Unicode)是为每个字符使用16位(两个字节)的字符集,因此能包括比ASCII更多的字符。Unicode可以有65536个字符,因此可用于对世界上的几乎所有语言进行编码。Unicode内包含ASCII字符集。
通常,在前版本的邮件客户机组件501具有指定的编码页、或者字符集和/或与之相关的语言。例如,特定版本的邮件客户机组件501可能有德语编码页,而另一版本可能有ANSI编码页。有时希望邮件客户机组件501接收除指定编码页之外的字符集所写的邮件。按照本发明一方面,最新版本的客户机组件可能迫使邮件服务器组件以Unicode提供所有邮件。一旦这些邮件被邮件客户机组件501所接收,则Unicode邮件可能转化成客户机的编码页,或者被保持为Unicode格式。
为了指明邮件客户机组件501要求以Unicode提供邮件,邮件客户机组件501可以把像FORCEUNICODE这样的标志提供给邮件服务器组件502。可以用ROP这样的请求来提供该标志。如果邮件服务器组件502是最新的版本,则邮件服务器组件502可以提供邮件的Unicode版本,如果可用,或者可以把其它字符集编码的邮件信息转化成Unicode。
图20示出按照本发明一方面为信息提供特定字符集的步骤。从步骤2001开始,邮件服务器组件502从其数据存储中检取信息。步骤2002中,确定是否存在FORCEUNICODE标志。如果不存在,则步骤2002分支到步骤2003,其中邮件服务器组件502以邮件客户机组件所指定的编码页来提供邮件信息,根据需要进行转化。
如果存在FORCEUNICODE标志,则步骤2002分支到步骤2004,其中确定信息是否被存储为Unicode。如果是,步骤2004就分支到步骤2005,其中以Unicode字符集把信息提供给邮件客户机组件501。如果信息未以Unicode被存储,则步骤2004分支到步骤2006,其中信息被转化成Unicode,然后进程继续到步骤2005,其中以Unicode把信息提供给邮件客户机组件。
在描述本发明的环境中所使用的不定冠词(a和an)和定冠词(the)以及类似指示物应被理解为既包括单数又包括复数,除非这里特别指明或与上下文明显矛盾。术语“由...组成(comprising)”、“具有(having)”、“包括(including)”和“包含(containing)”应被理解为开口的术语(即,意指“包括、但不限于”),除非特别指明。这里引用的值范围仅仅用作单独指示落在范围内各个独立值的简便方法,除非这里特别指明,且每个独立值都像在此被独立引用那样结合在说明书内。这里所示的所有方法都可以以任何适当顺序执行,除非这里特别指明,或者与上下文明显矛盾。任何或所有示例的使用、或者这里所提高到示例性语言(如,“譬如”)仅仅为了更好地阐明本发明,并且不使对本发明的限制,除非特别要求。说明书中的任何语言都不应被理解为对实践本发明基本的任何未经要求的元素。
这里描述了本发明的优选实施例,包括发明者所知用于实现本发明的最佳模式。在阅读了上述描述之后,那些优选实施例的变化对于本领域的普通技术人员是明显的。发明者希望技术人员能适当地采用这种变化,发明者意图用除这里特别描述的方式来实践本发明。因而,本发明包括对所附权利要求所引用的主要问题的所有修改和等价物,这被可适用的法律依据所允许。此外,除非这里特别指明或者与上下文明显矛盾,本发明包括了上述元件在所有可行变化中的任意组合。