使用时间建议来协调数据传递

摘要

基于与第一计算设备相关联的资源的已知电源开启时间来协调从多个第二计算设备到第一计算设备的数据传递。第二计算设备中的一个请求用于数据传递的时间间隔。第一计算设备将所请求的时间间隔与已知电源开启时间进行比较来确定传递时间。例如，将所请求的时间间隔对照使用资源的循环时间表的激活时间并且对照先前确定的传递时间来进行比较。第二计算设备在所确定的传递时间传递数据以保存资源。在某些实施例中，出于处理延时和网络等待时间来调整传递时间。

说明书

背景

近年来，诸如移动电话和个人数字助理(PDA)等移动计算设备已经变得日益流行。随着设备不断变小，在诸如存储器、存储、带宽和电池电量等资源方面存在日益增长的限制。另外，更多的应用程序现在正以日益增长的水平消耗着这些资源。例如，许多应用程序执行诸如与需要频繁使用无线电的服务器同步等的循环任务。在打开移动计算设备上的无线电的电源来发送数据之后，无线电需要花几秒钟来关闭电源(例如，在2.5G网络上大约3秒而在3G网络上大约20秒)。该无线电“尾”吸收电能并减短了移动计算设备上的电池寿命。此外，在自旋无线电和关闭无线电时存在其他的能源低效性。

移动用户正广泛地采用带有实时数据推送或更新的连接的应用程序。这些应用程序包括电子邮件、个人信息管理、在场信息和其他web应用程序。服务器用未经协调的方式来推送数据，从而使得移动计算设备上的电池寿命降级而负面地影响用户体验。

概述

本发明的各实施例协调从多个第二计算设备到至少一个第一计算设备的数据传递。该第二计算设备中的一个请求用于数据传递的时间间隔。第一计算设备将所请求的时间间隔与同第一计算设备相关联的通信资源的多个已知电源开启时间进行比较。确定传递时间并将传递时间提供给第二计算设备。协调数据传递保留了第一计算设备上的通信资源。在某些实施例中，出于处理延时和网络等待时间来调整所确定的传递时间。

提供本概述以便以简化形式介绍将在以下的详细描述中进一步描述的一些概念。本概述并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

附图简述

图1是示出第一计算设备从多个第二计算设备接收数据的示例性框图。

图2是示出用于存储资源的已知电源开启时间的计算设备以及用于实现本发明各方面的计算机可执行组件的示例性框图。

图3是示出将所请求的时间间隔与循环时间表的激活时间以及先前建议的传递时间进行比较来确定传递时间以向服务器提出建议的示例性流程图。

图4是示出确定数据传递时间并基于处理延时和网络等待时间来调整所确定的传递时间的示例性流程图。

图5是示出基于与移动计算设备相关联的通信资源的已知电源开启时间来确定数据传递时间的示例性流程图。

图6是示出从两个服务器到移动计算设备的数据传递的调度的示例性序列图。

在附图中，对应的附图标记指示对应的部分。

详细描述

参考附图，本发明的各实施例协调从多个第二计算设备104到至少一个第一计算设备102的数据传递以降低第一计算设备102上的通信资源的消耗。在某些实施例中，第一计算设备102向第二计算设备104提供传递时间的提示、建议、推荐或分配(例如，最优传递时间)从而使得多个第二计算设备104在同一时间或大约同一时间向第一计算设备102发送数据。在第一计算设备102是移动计算设备602的示例中，经协调的数据传递充分利用一个或多个蜂窝无线电的已知电源开启时间(例如，无线电自旋)来保存移动计算设备602上的电池寿命。然而，在其他示例中，本发明的各方面可用于保存第一计算设备102上的任何资源、降低其消耗、延长其寿命或对其进行优化。

在某些实施例中，移动计算设备602利用已知的调度数据来标识下一个排定的无线电时间，预留网络等待时间214，随后将该时间发布给感兴趣的应用程序或服务器。在一个示例中，所发布的时间稍早于下一个排定的无线电时间从而使得服务器通信和设备时间表两者都能充分利用同一个无线电自旋。例如，设备时间表是在上午9点激活，则所发布的时间是上午8:59:45。随后唤起无线电的服务器通信在上午8:59:45发生。

在有“模糊”或容限因子与时间表208中的每一个相关联的实施例中，容限因子向目标提供较大的时间窗口并协调第二计算设备104联系第一计算设备102的时间。在带有具有50％的容限因子的十分钟间隔时间表的示例中，第二计算设备104可以在时刻5和时刻10之间的任意时间联系第一计算设备102来充分利用无线电自旋。容限因子提高了充分利用无线电自旋的可能性。

再次参考图1，示例性框图示出第一计算设备102从多个第二计算设备104接收数据，该多个第二计算设备诸如第二计算设备#1到第二计算设备#N，其中N是正整数。第二计算设备104经由诸如例如因特网等网络106被连接到第一计算设备102。在某些实施例中，调度器108或其他组件、指令或逻辑对第一计算设备102执行诸如图3、图4和图5所示的操作。

第二计算设备104执行服务来周期性地(例如，定期地或间歇地)向第一计算设备发送数据。在某些实施例中，第二计算设备104向第一计算设备102提供实时内容更新(例如，push mail(推送邮件)、日历、联系人、即时消息收发和社交网络数据)。第二计算设备104还可以发送或接收心跳查验来保持第二计算设备104和第一计算设备102之间的连接畅通。

第二计算设备104包括但不限于，服务器、代理服务器、企业服务器、或将数据发送给第一计算设备102的任何其他设备。此外，虽然在某些实施例中参考包括移动计算设备602的第一计算设备102来进行描述，但本发明的各方面可用于诸如膝上型计算机、游戏控制台、手持式导航设备等其他设备、或与第二计算设备104进行通信的任何其他设备。另外，虽然本发明的各实施例参考将数据发送给移动计算设备602的服务器来进行描述，但本发明的各方面可在诸如第一计算设备102和第二计算设备104之间的对等连接等其他环境中操作。

接着参考图2，示例性框图示出用于存储资源的已知电源开启时间的计算设备202以及用于实现本发明各方面的计算机可执行组件，所述计算设备202诸如第一计算设备102。计算设备202包括处理器204和存储器区域206或其他计算机可读介质。存储器区域206存储多个时间表208，诸如时间表#1到时间表#M，其中M是正整数。时间表208与第二计算设备104相关联并由第二计算设备104提供来将数据发送给计算设备202。应用程序执行相应的时间表208来将数据发送至诸如相关联的第二计算设备104等设备或从所述设备中接收数据，这使得诸如计算设备202上的蜂窝无线电等通信接口的电源开启。例如，应用程序由计算设备202主存。时间表208中的每一个具有激活时间210，并且每一个时间表208与第二计算设备104中的至少一个相关联。在某些实施例中，时间表208具有循环激活时间210。

时间表208的执行包括在激活时间210完成或执行与时间表208相关联的一个或多个动作。例如，激活时间210将相关联的第二计算设备104要向计算设备202发送数据的时间表示为绝对值或偏移量。数据的传输使用计算设备202上的耗电资源(例如，诸如一个或多个蜂窝无线电等的通信资源或无线电资源)。虽然时间表208表示期间要使用通信资源的已知将来时间，但存储器区域206可以另选地或另外地显式地存储通信资源的一个或多个已知电源开启时间。

在某些实施例中，存储在存储器区域206中的时间表208包括条件时间表208、无条件时间表208、消耗通信资源的时间表208以及不消耗通信资源(或要被优化的其他资源)的时间表208。在这些实施例中，计算设备202在确定传递时间时过滤、搜索或以其他方式生成时间表208的子集。例如，无条件时间表208与条件时间表208相比具有较大的被执行的可能性(例如，最大执行可能性)，并且由此，在确定传递时间时，与无条件时间表208相关联的激活时间210被赋予比与条件时间表208相关联的激活时间210更高的优先级或偏好。

在其他实施例中，对时间表208进行预先排序、预先过滤或以其他方式进行分组。例如，存储器区域可以存储分开的条件、无条件、资源消耗和无资源消耗的时间表208的各组，以加快传递时间的确定。

存储器区域206还存储处理延时212和网络等待时间214。处理延时212表示由于计算设备202上的处理而导致的延时。网络等待时间214表示由于数据到计算设备202的网络106传输而导致的延时。在某些实施例中，处理延时212和网络等待时间214中的任一个或两者被表达为偏移量。计算设备202使用处理延时212和网络等待时间214来提供更准确的传递时间。在某些实施例中，处理延时212和网络等待时间214由计算设备202确定(例如，测量在处理或网络传输期间的时间差)。在其他实施例中，将网络等待时间214提供给计算设备202(例如，通过用设备将数据发送给计算设备202)。

存储器区域206还存储一个或多个先前确定的传递时间216。先前确定的传递时间216表示用于向计算设备202传递数据的提示时间或建议时间。先前确定的传递时间216表示在将来发生的时间。在当前时间是下午12:30的示例中，计算设备202确定传递时间为下午12:40并将该传递时间提供给第一应用程序。在从第二应用程序接收到传递时间的请求之后，计算设备202知晓先前确定的传递时间为下午12:40并能够考虑将该时间提供给第二计算设备104来协调计算设备202上的通信资源的使用，如以下参考图3更详细地描述的。

存储器区域206还存储一个或多个计算机可执行组件，诸如接口组件218、高速缓存组件220、提示组件222和发布组件224。这些组件的操作在下文中参考图5来描述。

接着参考图3，示例性流程图示出将所请求的时间间隔与时间表208的激活时间210以及先前建议的传递时间216进行比较来确定传递时间以向服务器提出建议。在302处，诸如第一计算设备102等的计算设备从诸如服务器或第二计算设备104等的另一计算设备接收所请求的时间值。在某些实施例中，时间值包括指定最小时间值和最大时间值的时间间隔或范围。时间值可以是绝对时间或离当前时间(例如，第一计算设备102所接收的时间)的偏移量。在附录A中示出用于指定时间间隔的示例手段。

在接收到所请求的时间值之后，第一计算设备102在304处标识与时间表208相关联的一个或多个即将到来的激活时间210。例如，第一计算设备102标识与消耗通信资源(或要被优化的其他资源)的时间表208相关联的激活时间210。第一计算设备102随后标识与无条件时间表208相关联的那些激活时间210。如果没有这样的时间表208可用，则第一计算设备102标识与条件时间表208相关联的那些激活时间210。

同样在304，第一计算设备102标识一个或多个先前确定的传递时间216。例如，第一计算设备102访问存储在存储器区域206中的先前确定的传递时间216。在306处，将所请求的时间值与所标识的激活时间210以及先前确定的传递时间216进行比较。同样在306，基于该比较，第一计算设备102确定传递时间。在所请求的时间值是间隔的示例中，所确定的传递时间表示该间隔内的时间。另选地或另外地，所确定的传递时间表示与即将到来的激活时间210中的一个或者与先前确定的传递时间216中的一个相对应的时间。在这些实施例中，因为在通信资源的电源开启的同时多个服务器将使用该通信资源，所以优化了通信资源的使用。

在308，将所确定的传递时间提供给服务器。服务器在所提供的传递时间将数据发送给第一计算设备102。在某些实施例中，所请求的时间值是从在第一计算设备102上执行的但与服务器相关联的应用程序接收的。在这些实施例中，将所确定的传递时间提供给该应用程序。该应用程序将所确定的传递时间传达给服务器，并且服务器在所确定的传递时间将数据发送给第一计算设备102。

在多个服务器企图向第一计算设备102发送数据的实施例中，该多个服务器中的每一个具有与其相关联的优先级。第一计算设备102在确定传递时间时使用所分配的优先级。例如，如果通信资源在特定时间间隔可用，则提出传递时间请求的具有高优先级的服务器将在特定时间间隔的较早时刻接收到所确定的传递时间。具有较低优先级的服务器将在特定时间间隔的较晚时刻接收到所确定的传递时间。

接着参考图4，示例性流程图示出确定数据传递时间并基于处理延时212和网络等待时间214来调整所确定的传递时间。在402处，访问由服务器或其他第二计算设备104请求的时间间隔(例如，由第一计算设备102访问)。所请求的时间间隔表示期间服务器想要向第一计算设备102发送数据的时间范围。在404处，搜索激活时间210(在某些实施例中，连同先前确定的传递时间216)来标识在所请求的时间间隔内的激活时间210的子集。在406处，基于所标识的激活时间210的子集来确定传递时间以协调通信资源的消耗。在408处，基于与处理延时212和/或网络等待时间214相对应的偏移量来调整所确定的传递时间。在410处，将所确定的传递时间发布给服务器。

在附录B中描述了用于确定传递时间的示例性指令或操作。

接着参考图5，示例性流程图示出基于与移动计算设备602相关联的通信资源的已知电源开启时间来确定数据传递时间。在图5的示例中，接口组件218、高速缓存组件220、提示组件222或发布组件224在移动计算设备602上执行。在502处，接口组件218接收或访问所请求的时间间隔或值。该时间间隔与从服务器到移动计算设备602的预期数据传输相关联。在504处，高速缓存组件220标识移动计算设备602上的通信资源的一个或多个预期电源开启时间。该预期电源开启时间表示，例如在移动计算设备602上执行的消耗通信资源的时间表208的即将到来的激活时间210或先前确定的传递时间216。

在506处，提示组件222基于由接口组件218接收的所请求的时间间隔与由高速缓存组件220标识的预期电源开启时间的比较来确定传递时间。例如，提示组件222将传递时间设为与预期电源开启时间中的一个相对应的时间间隔的起点。在某些实施例中，接口组件218所接收的请求包括表示数据传输的预期大小的有效负载值。在这些实施例中，提示组件222基于所接收的有效负载值来确定传递时间以管理移动计算设备602上的带宽(例如，为了避免使通信资源发生颠簸)。例如，带有小有效负载的数据包被排定为首先发送的优先级，接着是带有大有效负载的数据包。作为有效负载大小的替代或除了有效负载大小之外，对于遍历某些接口的有效负载赋予优先级并按照优先级降序来发送。

在508处，发布组件224将由提示组件222确定的传递时间提供给服务器。服务器在所提供的传递时间将数据发送给移动计算设备602。

在某些实施例中，移动计算设备602具有多个蜂窝无线电。在这些实施例中，接口组件218所接收的请求包括该多个蜂窝无线电中的一个的标识。在其他实施例中，移动计算设备602将请求分配给该蜂窝无线电中的一个。在另一些实施例中，跟踪时间表208中具有持久连接的每一个时间表所使用的无线电。所标识的蜂窝无线电变为提示组件222用来确定传递时间的另一变量。在这些实施例中，存储在存储器区域206中的先前确定的传递时间216中的每一个包括相关联的蜂窝无线电的标识。提示组件222在确定传递时间时对具有相同所标识的蜂窝无线电的时间表208排定优先级。

接着参考图6，示例性序列图示出从两个服务器到移动计算设备602的数据传递的调度。在移动设备上执行的两个应用程序604、606请求到移动计算设备602的数据传递的提示。在从调度器108接收到提示之后，应用程序604、606将提示提供给相关联的服务器610、612。服务器610、612随后试图在所提示的时间将数据发送给移动计算设备602。

在图6的示例中，已知电源开启时间(例如，即将到来的激活时间210或先前确定的传递时间216)的列表被称为ServerSendTime(服务器发送时间)列表。在调度器108或其他服务的启动期间创建ServerSendTime列表并且当调度器108结束处理时将其清除。ServerSendTime列表作为高速缓存来对待从而使得如果高速缓存条目落在所请求的时间间隔之间，则在确定另一传递时间时将该高速缓存条目认为是候选。在某些实施例中，高速缓存被表示为带有<key，value>＝<ServerSendTime，frequency>(<关键字，值>＝<服务器发送时间，频率>)的散列映射。<ServerSendTime，frequency>的映射按照关键字(ServerSendTime)来排序。在该示例中，映射加快了最接近结束时间的ServerSendTime的标识。

在某些实施例中，时间表208中的每一个的激活时间210被存储为按激活时间210(例如，升序)排序的高速缓存。高速缓存存储所有活动时间表208的激活时间210。用每一个从服务器接收的要传递数据的请求来创建或更新高速缓存。在某些实施例中，调度器108简单地提供或发布该高速缓存以使服务器能够选择合适的传递时间。

在图6的示例中，在接收到所请求的时间间隔之后，调度器108在高速缓存中迭代并删除已经到期(例如，具有早于当前时间的激活时间210)的所有条目。调度器108在时间表208中迭代来标识使用移动计算设备602上的通信资源的活动且循环的时间表208的子集。计算时间表208子集中每一时间表208的下一个激活时间210。从时间表208的该子集中，调度器108标识落在服务器所请求的时间间隔内的激活时间210。调度器108对与具有高执行确定性的时间表208相关联的激活时间210赋予偏好。例如，带有无条件执行的时间表208具有高执行确定性。调度器108基于所标识的时间表208子集来更新激活时间210的高速缓存。

调度器108基于激活时间210的高速缓存和ServerSendTime列表来确定传递时间或其他提示时间。如果激活时间210中的一个落在所请求的时间间隔内，则将该激活时间210添加到ServerSendTime列表，并且将频率设为一。如果在激活时间210的高速缓存中没有满足的激活时间210，则调度器108扫描ServerSendTime列表。如果ServerSendTime中的一个落在所请求的时间间隔内，则将该ServerSendTime提供给提出请求的服务器并且在列表中递增该ServerSendTime的频率。如果一个以上的ServerSendTime落在间隔内，则选择具有最高频率的ServerSendTime。如果没有一个ServerSendTime落在所请求的时间间隔内，则选择最接近的ServerSendTime(例如，基于定义的容限或增量区域)。将传递时间设为最接近的ServerSendTime的起点。如果没有ServerSendTime落在时间间隔内，则将所请求的时间间隔的结束时间设为ServerSendTime。随后将结束时间输入到ServerSendTime列表中，其频率为一(1)。

虽然图6的示例示出示例性的传递时间确定，但其他选择方法也在本发明各方面的范围之内。此外，选择方法可以动态地改变。

在某些实施例中，最小时间值是当前时间而最大时间值表示最大心跳间隔(例如，移动计算设备602和服务器在不传输数据但仍然保持连接的情况下所能持续的最长时间段)。

在一实施例(未示出)中，服务器是集结来自一个或多个服务器的数据的代理服务器。代理服务器在将数据发送给移动计算设备602之前集结数据。代理服务器向数据包(或向服务器)分配优先级。优先级表示将该数据包发送给移动计算设备602的紧急度(例如，与延时该包的容忍度相对)。代理服务器用在发送数据之前等待的意愿(例如，按分钟)来量化优先级。在移动计算设备602上，应用程序提供最小时间(例如，当前时间)以及和发送该数据包的服务器愿意延迟数据传递的时间段相等的最大时间。当移动计算设备602应用程序将心跳查验发送给服务器时，它包括所确定的传递时间或对于服务器发送数据的最优将来时间的提示。

ServerSendTime表示服务器发送数据的开始时间。在已知ServerSendTime之后的某时间段资源可用(例如，蜂窝无线电尾)的实施例中，调度器108考虑该时间段。例如，基于已知蜂窝无线电尾来设置容限或增量区域。

示例

在一示例中，邮件服务器要求提示并提供12:00和12:20作为最小和最大时间。调度器108具有带有在12:20的10分钟间隔时间段时间表的活动连接的活动时间表。调度器108标识活动时间表，调整传递时间以考虑网络等待时间214和/或处理延时212(例如，三十秒)，确定传递时间为12:19:30，并且将所确定的传递时间提供给服务器。

在上述示例的变型中，没有激活时间210落在所请求的时间间隔内。在该示例中，调度器108将12:20的最大时间设为所确定的传递时间(例如，ServerSendTime)。

在上述示例的延续中，另一服务器提供了12:15和12:30作为最小和最大时间。ServerSendTime等于12:20，落在所请求的时间间隔内。在调整了网络等待时间214之后，调度器108提供12:19:30作为所确定的传递时间。

示例性操作环境

作为示例而非限制，计算机可读介质包括计算机存储介质和通信介质。计算机存储介质存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。以上的任一种的组合也包括在计算机可读介质的范围之内。

尽管结合示例性计算系统环境进行了描述，但本发明的各实施例可用于众多其它通用或专用计算系统环境或配置。适用于本发明各方面的公知的计算系统、环境和/或配置的示例包括，但不限于：移动计算设备、个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、游戏控制台、基于微处理器的系统、机顶盒、可编程消费电子产品、移动电话、网络PC、小型机、大型计算机、包括上述系统或设备中的任一个的分布式计算机环境等等。

可以在由一台或多台计算机或其他设备执行的诸如程序模块之类的计算机可执行的指令的一般上下文中来描述本发明的各实施例。计算机可执行指令可以被组织成一个或多个计算机可执行组件或模块。一般而言，程序模块包括，但不限于，执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件，以及数据结构。可以利用任何数量的这样的组件或模块及其组织来实现本发明的各方面。例如，本发明的各方面不仅限于附图中所示出并且在此处所描述的特定计算机可执行指令或特定组件或模块。本发明的其他实施例可以包括具有比此处所示出和描述的功能更多或更少功能的不同的计算机可执行指令或组件。

此处所示和所描述的各实施例以及此处未具体描述的、但落在本发明的各方面的范围内的各实施例构成用于基于所请求的时间间隔内的无线电资源的已知电源开启时间来确定传递时间的示例性手段，以及用于基于处理延时212和等待时间来调整传递时间的示例性手段。

此处所示出和描述的本发明的各实施例中的操作的执行或实现的顺序不是必需的，除非另外指定。即，除非另外指定，否则操作可以按任何顺序执行，且本发明的各实施例可以包括比此处所公开的操作更多或更少的操作。例如，构想了在一个操作之前、同时或之后执行另一个操作是在本发明的各方面的范围之内的。

当介绍本发明的各方面的元素或其实施例时，冠词“一”、“一个”、“该”、“所述”旨在表示有元素中的一个或多个。术语“包括”、“包含”以及“具有”旨在是包含性的，并意味着除所列出的元素以外还可以有额外的元素。

已经详细地描述了本发明的各方面，显然，在不偏离所附权利要求书所定义的本发明的各方面的范围的情况下，可以进行各种修改和变化。在不偏离本发明的各方面的范围的情况下，可以对上面的构造、产品以及方法作出各种更改，上面的描述中所包含的和各个附图中所示出的所有主题应该解释为说明性的，而不是限制性的。

附录A

以下所示的应用程序编程接口(API)使得应用程序能够提供最小时间和最大时间间隔。在第一计算设备上执行的调度器返回落在两个间隔之间的提示(例如，用统一时间代码格式)。API签名如下所示。

//先决条件：-

//   startTime＜＝endTime(开始时间＜＝结束时间)

//   CurrentTime＜＝endTime(当前时间＜＝结束时间)

//后置条件：-

//   startTime＜＝serverSendTime and serverSendTime＜＝endTime(开始时间＜＝服务器发送时间并且服务器发送时间＜＝结束时间)

HRESULT TaskSchedulerGetBestNetworkTimeInRange(__in const FILETIME*startTime，__in const FILETIME*endTime，__out FILETIME*serverSendTime)；

该API获得提示时间以便服务器在startTime(开始时间)和endTime(结束时间)之间将数据发送给设备。

参数

startTime

[输入]间隔的开始时间。

endTime

[输入]间隔的结束时间。

serverSendTime

[输出]服务器需要将数据发送给设备的提示时间。

返回值

S_OK

如果成功则返回的值。

E_INVALIDARG

如果任何先决条件失败或者对于无效自变量返回的值。

E_FAIL

如果不成功则返回的值。

以下示出用于取消先前由TaskSchedulerGetBestNetworkTimeInRange()返回的提示的示例性API。该API由最终未使用提示的任何请求者使用。至少因为在发布时所提示的时间具有较高的权重，所以该API提高了本发明的各方面的准确性和有效性。有了该API函数调用，调度器紧密地跟踪提示时间值的使用并且改进在稍后分发提示时间时调度器内部使用的试探法。在以下示例中，使用TaskSchedulerCancelBestNetworkTime(任务调度器取消最佳网络时间)来取消现有提示的调用者(帐户)和使用TaskSchedulerGetBestNetworkTimeInRange(任务调度器获得范围内最佳网络时间)来获得提示的调用者(帐户)是同一个。

HRESULT TaskSchedulerCancelBestNetworkTime(__in const FILETIME*serverSendTime)；

参数

serverSendTime

[输入]先前由TaskSchedulerGetBestNetworkTimeInRange返回的提示时间。

返回值

S_OK

提示时间的发布已被跟踪。

S_FALSE

提示时间未被识别(值已经“到期”或者值不是由TaskSchedulerGetBestNetworkTimeInRange先前返回的)。

E_*

在处理请求时遭遇其他失败。

附录B

以下示出了用于确定传递时间的示例性指令或操作。

在服务启动期间创建ServerSendTime列表并且当服务停止时将其清除。该列表作为高速缓存来对待从而使得如果高速缓存条目落在间隔之间，则该高速缓存条目可以被认为是ServerSendTime的候选而不必在所有时间表中迭代并再次计算ServerSendTime。高速缓存可以内部地被表示为带有<key，value>＝<ServerSendTime，mapAcctIdtoFreq>(<关键字，值>＝<服务器发送时间，帐户Id到频率的映射>)的散列映射，其中mapAcctIdtoFreq是所有者帐户id到频率的散列映射，并且可以被定义为：

map<ACCTID，DWORD>mapAcctIdtoFreq；

<ServerSendTime mapAcctIdtoFreq>的映射按照关键字(ServerSendTime)来排序。

还维护按NRT(下一运行时)来排序的<NRT>列表。该列表在每次调用API时创建。该列表存储所有活动时间表的NRT。

接着描述用于确定传递时间的示例性算法。

1.在高速缓存中迭代并删除已经到期的所有条目(例如，NRT＜CurrentTime(下一运行时＜当前时间)的那些条目)。

2.如果starttime＝＝endTime(开始时间＝＝结束时间)，如果该值不存在高速缓存<ServerSendTime，mapAcctIdtoFreq>中，则将该值添加到该高速缓存，否则如果ServerSendTime已经存在于高速缓存中，则添加/递增mapAcctIdtoFreq中的频率。

3.如果在注册表中定义了ShrinkFactor(收缩因子)，则基于收缩因子来缩减(starttime-endTime)间隔。将Starttime推送为newStartTime(新的开始时间)并且间隔变为(newStartTime-endTime)。

如果未定义，则newStartTime＝starttime。

这么做是为了使得hinttime(提示时间)总是接近结束时间。

4.在组集合中迭代。

5.在每一组中的所有时间表中迭代。

6.只考虑满足以下条件的时间表。

a)Recurrence！＝BOOTUP(循环！＝引导)

b)Network Connectivity＝TRUE(网络连接＝真)(不带有网络连接的时间表不被认为是SendServerTime，因为它们也许能或也许不能帮助缩减无线电自旋)

c)如果IsCellularPreferred＝1(蜂窝被优选＝1)，则只考虑带有CELLULAR＝ON(蜂窝＝开启)的时间表。如果IsCellularPreferred＝0(蜂窝被优选＝0)，则不考虑CELLULAR(蜂窝)条件。

d)Active＝TRUE(活动＝真)。所考虑的时间表包括当前活动的并且在给定newStartTime-endtime且满足MaxRuncounts(最大运行计数)条件时将来将保持活动的时间表。

7.如接下来所述地从在步骤6中创建的列表中创建ServerSendTime。

对于列表(例如，在步骤6中创建的)中选择的每一个时间表，计算第N个运行时。使用公式来计算第N个运行时。

对于循环平均

NRT(N)＝NRT(N-1)+CurrentIntervalDuration(当前间隔持续时间)

对于循环间隔

NRT(N)＝NRT(N-1)+CurrentIntervalDuration(当前间隔持续时间)

其中NRT(0)＝组活动时间表的下一运行时。

只考虑属于以下两种类别的时间表。

a)无条件且是组中仅有时间表的时间表

b)无条件时间表且组中的所有其他时间表也都无条件。

如果组中存在至少一个带有某些条件的时间表，则不将该组考虑为ServerSendTime。

8.这得到<NRT>列表和<ServerSendTimes，mapAcctIdtoFreq>的高速缓存。接着，选择间隔<newStartTime，endTime>中的“最佳”提示时间。基于注册表设置IsPreferredCache(高速缓存被优选)，至少两种排列是可能的

a)如果IsPreferredCache＝1(高级缓存被优选＝1)，则首先在高

速缓存<ServerSendTimes，mapAcctIdtoFreq>中查找

ServerSendTime。

如果只找到一个ServerSendTime，则转到步骤10。

如果找到多个ServerSendTime值，则查找带有最大频率的

ServerSendTime并转到步骤10。

如果找到多个ServerSendTime值且两个或更多ServerSendTime

带有相同的最大值，则选择基于UseEndtime(使用结束时间)

注册表值的那个值。

如果UseEndTime＝1

则选择接近结束间隔的值

如果UseEndTime＝1

则选择接近开始间隔的值

否则，如果在高速缓存中未找到，则查看列表<NRT>

b)如果IsPreferredCache＝0(高速缓存被优选＝0)，则首先在列

表<NRT>中查找ServerSendTime。如果找到ServerSendTime，

则转到步骤10。

如果找到多个NRT，则选择基于UseEndTime注册表值的那个

值

如果UseEndTime＝1

则选择接近结束间隔的值

如果UseEndTime＝1

则选择接近开始间隔的值

否则，如果在列表<NRT>中未找到，则查看高速缓存

<ServerSendTime，mapAcctIdToFreq>

9.如果从步骤8未找到ServerSendTime，则

如果ShrinkFactor＝0

计算增量区域并在增量区域中从高速缓存

<ServerSendTime，mapAcctIdtoFreq>查找

ServerSendTime。增量区域可以被认为是

Starttime-增量到Starttime

如果在增量区域中也没有找到ServerSendTime，则基于

UsedEndTime注册表值来赋值ServerSendTime

如果UseEndTime＝1

则ServerSendTime＝Endtime

如果UsedEndTime＝0

则ServerSendTime＝StartTime

如果ShrinkFactor＝1

因为starttime已经被推送为新的值，所以在这种情况下

无法检查增量区域。

将ServerSendTime赋值为EndTime。

ServerSendTime＝Endtime

10.如果从步骤8找到了ServerSendTime，则

a.用NetworkLatencyAdjustment(网络等待时间调整)来调整

ServerSendTime

ServerSendTime＝ServerSendTime-NetworkLatencyAdjustment

检查是否新的ServerSendTime＞StartTime。(未应用ShrinkFactor

的StartTime)

如果否，则赋值ServersendTime＝StartTime。(未应用ShrinkFactor

的StartTime)

11.现在计算ServerSendTime，在高速缓存<ServerSendTimes，mapAcctIdtoFreq>中查找该ServerSendTime值。

a.如果在高速缓存中未找到，则添加该值以及所有者帐户id的值并且频率＝1

b.如果在高速缓存中找到，则查找帐户id。如果帐户id也存在，则递增频率。如果帐户Id不存在，则添加该帐户id并且频率＝1。

12.如果用某一时间值来调用TaskSchedulerCancelBestNetworkTime，则将在高速缓存<ServerSendTimes，mapAcctIdtoFreq>中搜索该值。如果在高速缓存中找到该值，则在相应的mapAcctIdtoFreq中搜索所有者帐户id。如果在mapAcctIdtoFreq中找到某一值，则递减频率。

当频率＝0时，将该条目从mapAcctIdtoFreq中移除。

同样，如果mapAcctIdtoFreq为空，则将ServerSendTime值从高速缓存<ServerSendTimes，mapAcctIdtoFreq>中移除。

注意：

1)NetworkLatencyAdjustment是使用网络等待时间和处理延时来确定的值。这是考虑网络等待时间的可配置注册表条目。每次返回ServerSendTime时，应该用NetworkLatencyAdjustment来设置偏移量。

2)如果设备的绝对时间改变，则需要基于该时间改变来调整高速缓存<ServerSendTime，frequency>中的时间值。这可以通过用时间改变事件的通知注册来完成。

3)可能存在用将来太过遥远的开始/结束时间(例如，间隔是10年以后)调用API的场景。在这种情况下，在API中执行边界检查(例如，间隔是在从当前时间起的24小时之内)而非计算NRT<N>。

4)包括StarttimePreferred/EndtimePreferred(开始时间优选/结束时间优选)和FrequencyPreferred(频率优选)的注册表值是可配置注册表条目。基于这些注册表值，可以动态地改变选择算法。