CN102591682A

CN102591682A - 预测性的软件流传输

Info

Publication number: CN102591682A
Application number: CN2011104469077A
Authority: CN
Inventors: D.特珀; E.霍尔维茨; T.布尔丁
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2010-12-28
Filing date: 2011-12-28
Publication date: 2012-07-18
Anticipated expiration: 2031-12-28
Also published as: WO2012092326A3; US9043782B2; WO2012092326A2; EP2659387A4; EP2659387A2; US20120167075A1; EP2659387B1; CN102591682B

Abstract

可以实现一种软件流传输平台，该平台基于下载程序单元的值来预测地选择所要下载的程序单元。在一个示例中，程序被分成块。分析历史上已被请求的程序块的序列，以便针对给定的历史确定接下来最有可能被请求的块。然后，这些块可以合并成组块，其中每一个组块表示在序列中出现的可能性很高的一连串的块。然后，构造一个表格，该表格针对给定的组块指示最有可能跟随在该给定的组块之后的组块。基于这个可能性表格以及各种其他考虑因素，确定下载特定组块的值，并且下载具有最高预期值的组块。

Description

预测性的软件流传输

背景技术

传统上，当在机器上执行软件时，在软件可以运行之前必须将整款软件安装在该机器上。然而，有可能使用流传输技术从远离将要执行软件的机器的位置提供软件。在流传输情景中，机器A可以执行从机器B流传输至机器A的软件。这样一来，机器A可以执行一款软件（a piece of software）的一些组件，即便机器A上存在的组件少于全部组件。

针对在其上执行软件的机器来说，一种用于实现此类型软件流传输的方式是按需请求软件组件。举个例子，假设该软件是一个游戏，在该游戏中，用户从一个场景行进到另一个场景，并且选择下一步去往哪里。如果每一个场景都是软件的一个组件，那么用户选择去往的方向确定了下一步必须执行哪一个场景——由此确定必须执行哪一个组件。作为响应，游戏可以获取组件，并且简单地等待了解用户想要去哪儿，并且请求与用户的选择相对应的组件。虽然游戏提供被分成组件的软件的简单示例，但是理论上几乎任何软件都可以采用这种方式来模块化——例如文字处理器可以具有一个用于“打印预览”功能的组件，另一个用于“打印”的组件，还有一个用于“绘制表格”的组件等等。

在以这种方式流传输软件时，有可能会出现一个问题，那就是用户可能必须等待组件被下载。如果组件只在用户已经请求执行这些组件的时候才被下载，那么在首次使用组件时该组件在用户的机器上将是不可用的，并且用户将必须等待该组件被下载。关于软件流传输平台质量的一个量度是用户等待使用程序的正在下载的部分所耗费的时间量（或者相反缺乏时间量）。通过该量度，按需平台可以提供低于所能实现的质量。

发明内容

在软件流传输平台中，软件可以以预测方式被流传输，使得可以在实际请求使用软件组件之前将其下载到使用这些组件的机器。为了高效使用有限的传输带宽，该平台尝试预测接下来可能使用哪一个（些）组件，然后则在实际请求使用这些组件之前使用另外的闲置的资源来下载这些组件。

为了支持组件的预测性下载，软件被分成了单元，并且构建了指示软件数据的每一个单元成为接下来将要下载的软件数据单元的可能性模型。该模型是依照历史——即，哪些组件已经被请求且按照什么顺序进行——来预测软件的特定单元将被下载的可能性。由此，如果将软件分成单元A、B、C、D和E，那么可以确定C、D、E中的每一个跟随在序列AB之后的可能性。举个例子，C将跟随在AB之后的概率可能是0.5，D将跟随在AB之后的概率可能是0.3，以及E将跟随在AB之后的概率可能是0.2（存在定义什么构成软件“单元”的很多种方式，这些方式的示例是在以下的具体实施方式部分中描述的）。这种概率信息可以用于构建可能跟随在AB之后的软件单元的列表及其可能性的顺序。例如，C最有可能跟随在AB之后，并且D和E分别是第二和第三最有可能跟随在AB之后的组件。AB是历史的示例，然而类似的列表可以针对其他任何历史构建（例如，列表可以构建很有可能跟随在BD之后的那些单元的列表。此外，从历史是由最后两个被请求的单元定义的意义上讲，AB是大小为2的历史，但是历史的大小既可以是1，也可以是3，还可以是其他任何大小）。

在创建了显示哪些软件单元可以遵循一给定历史且以什么可能性遵循给定历史的列表时，可以做出关于要下载哪些单元以及以什么顺序下载的决定。通常，当实际请求的是尚未下载的单元时，系统会下载该单元。但是，在不存在针对软件的任何部分的未得到满足的请求时，系统尝试通过下载那些可能通过减少未来等待时间来增强未来用户体验的项目而有效地使用闲置资源。为了决定要下载什么，系统尝试估计特定单元的下载价值，然后设法下载价值最高的单元。如果单元可能具有不同的大小，那么一个考虑因素是较大的单元通常具有较高的价值，这是因为当用户最终的确请求该单元时，未下载大单元的代价是更长的等待。另一个问题是预测将实际使用所下载的单元的可能性，这是因为——在所有其他条件相同的情况下——较高的使用可能性意味着预先下载该单元的价值较高。此外，有可能是以广度优先遍历（按照可能性的顺序下载所有可能遵循当前历史的单元）或是深度优先遍历（下载下一个单元，之后是可能跟随下一个单元的单元等等）下载单元。广度优先和深度优先遍历可以与不同的成本曲线相关联，由此系统可以通过基于哪一个选择具有较低成本而使用广度优先或深度优先遍历来从该过程中的任何判定点继续找出下一个将要下载的单元。

本发明内容被提供以通过简化形式引入在以下的具体实施方式中进一步描述的构思的选择。本发明内容不旨在确定要求保护的主题的关键特征或必要特征，也不旨在用于限制要求保护的主题的范围。

附图说明

图1是接收流传输软件的示例过程的流程图。

图2是识别程序的哪一个单元很可能遵循给定的历史的示例过程的流程图。

图3是示例图表的框图。

图4是图3中的图表的表格表示的框图。

图5是将节点一起组合成组块的示例图表的框图。

图6是示例预测列表的框图。

图7是可以结合这里描述的主题的实现方式使用的示例组件的框图。

具体实施方式

对于早期的计算技术来说，软件是作为单个单元提供给计算机的。如果想在特定机器上执行某款软件，那么通常该软件作为单个单元被递送到该机器（例如借助磁带，借助可移除盘，借助网络连接等等）。在软件的任何使用之前，整款软件通常会被下载并安装在机器上。然而，现今有可能将软件流传输到执行该软件的机器上。软件可以被模块化，并且可以在执行软件的时候将特定的模块（或是其他类型的组件）递送到计算机。模块甚至可以在尚未下载其他模块时执行。

这种模块化工作所处场景的一个典型示例是游戏程序的情形。游戏通常涉及影响游戏下一步将会采取的行动的用户决定。例如，用户处于房间中并且选择向左还是向右移动。每一个方向都会导致另一个场景，并且每一个场景都可以由程序的组件来实现。由此，接下来将要执行的特定组件取决于用户选择移动的方向。虽然游戏是这种情形的一个示例，但是理论上任何软件都可以采用这种方式工作。例如，在文字处理程序中，诸如“打印预览”、“打印”、“保存”等功能可以由单独的组件来实现。

在以这种方式将软件模块化时，有可能从远程位置流传输软件。由此，即使在机器上不存在实现游戏中的某些场景的组件，游戏也可以在该机器上执行。类似地，即使在机器上不存在实现某些功能的组件，文字处理器也可以在机器上执行。（例如，即使尚未将执行打印功能的组件下载至用户机器，文字处理器也可以允许用户编辑文档。）。理论上，允许这种流传输的平台可以建立在“懒惰（lazy）”范式上，其中每一个组件都是在请求使用该组件的时候下载的。但是，这种懒惰技术可能使用户等待下一个模块。举个例子，如果游戏玩家在游戏中去往一个特定场景，并且游戏引擎仅仅在用户访问该场景时才下载用于该场景的模块，那么用户将必须在其首次访问每个场景的时候等待该场景下载。实际上，在后续访问相同场景的时候，用户可能必需等待下载，这是因为玩该游戏所在的机器可能具有有限的资源来存储程序组件，并且可能在各种不同的时间从其存储器中刷新（flush）较旧的组件，以便为新的组件腾出空间。从用户必须等待下载的时间长度是流传输软件平台质量的量度的意义上讲，懒惰下载方案可能导致劣质的平台。

这里描述的主题使用了预测技术来实现流传输软件平台，以便尝试为用户提供相对较低的等待时间。该预测流传输软件平台通过尝试预测在软件执行过程中接下来有可能使用什么软件组件而在使用所述软件组件之前下载这些组件。所述预测可以基于任何类别的统计模型。然而，其思想通常是事件发生概率可根据已发生什么事件（“历史”）而改变。由此，假设软件具有用A-Z标记的26个组件。如果不知道软件已被如何使用，那么下载组件Q的概率可能是0.01。然而，如果知道已被使用的最后三个组件是G、V和X，按照该顺序，那么可能知道（基于使用模式的历史）Q将是下一个要被使用的组件的概率是0.50，这明显高于Q将被使用的一般总体概率。（或者与此相反，可能知道Q未曾跟随在G-V-X之后，在这种情况下，Q将是该序列之后的下一个组件的概率是0）。给定使用模式的一些分析，有可能创建一个模型，该模型针对每一个组件指示该组件的使用将遵循某些组件使用历史的概率。

为了预测接下来将要使用的软件单元，必须具有什么构成软件“单元”的概念。在一个示例中，软件单元是“组件”——即软件的功能单元，例如在特定游戏中实现“hall of mountain king”场景的程序部分或是文字处理器中的“打印预览”功能。然而，在示例实现方式中，软件可以分成“块”，其中每一个块都可以仅仅是表示程序中的特定数据量的单元（例如某数量的千字节）。如果连续的块伴随出现的概率足够高，则可以将块集合成“组块”。由此，如果程序包含了块A-Z，那么G是其中一个块。如果在使用了G之后使用X的概率是0.9，那么序列G-X可以被认为是“组块”。如果R跟随在G-X之后的概率是0.95，那么可以将R添加到组块中，由此使得G-X-R成为一个组块。如果假设B跟随在G-X-R之后的概率是0.4，并且没有一个块跟随在G-X-R之后的概率更大，那么可以停止向该组块添加附加的块，这是因为没有一个块跟随在G-X-R之后的概率高到使得将附加的块视为是与G-X-R相同单元的部分是有意义的。可以确立阈值（例如0.9），以使得系统将尝试将块合并到组块中，直至没有一个块跟随在现有组块之后的机会超过或等于该阈值。

因此，这里的主题使用了软件“单元”，在决定接下来将要下载什么的过程中，在系统选择特定“单元”而不选择小于一个单元的软件部分的意义上讲，该软件单元是原子性的（atomic）。但是，该“单元”可以是软件的功能组件、“块”、“组块”（如上所述）或是其他任何类型的单元。应该指出的是，在系统不决定下载小于一个单元的软件部分的意义上讲，“单元”是原子性的，但是实际的下载技术细节可能允许下载小于单个单元。举个例子，如果组块包括三个块，那么有可能下载组块中的一个块（或甚至小于单个块），然后响应于刚好接收的用户请求而暂停下载组件，之后则继续下载组块中的下一个块。将块一起组合成组块的重要性在于：决定接下来将要下载什么的系统可以决定特定组块（即块的序列）是接下来将要下载的“单元”。（虽然在程序的功能组件与“组块”之间存在概念上的差别，但是在实践中，“组块”很有可能——虽然并不是绝对确定——对应于功能单元。如果频繁出现请求块B跟随在请求块A之后的情形，那么块A和B很有可能是相同功能单元的一部分）。

一旦确定了什么构成了软件“单元”，则可以分析在另一个单元之后使用给定单元的概率。换言之，给定某有序对的软件单元（α，β），则有可能确定（例如基于对历史使用模式的分析）在使用α之后使用β的概率。在统计语言中，如果h是被请求的单元的历史，那么可以定义一个条件概率分布函数，对于任何单元x来说，

是x将跟随在h之后的概率。特定的系统可以选择固定的历史大小，例如单个单元、两个单元、三个单元等等。因此，在历史大小是三个单元的示例中，可以针对每个三单元序列确定任何特定单元将跟随在该序列之后的概率。如果u ₁ 、u ₂和u ₃是在序列u ₁ -u ₂ -u ₃中使用的三个单元，那么可以定义一个条件概率分布函数

，该函数表示任何给定单元x将跟随在序列u ₁ -u ₂ -u ₃之后的概率。

使用条件概率分布，可以为任一值n确定哪一个单元是第n个最有可能遵循任意给定历史的单元。举个例子，可以假设u ₅₇最有可能跟随在u ₁ -u ₂ -u ₃之后，u ₄₃第二最有可能跟随在u ₁ -u ₂ -u ₃之后，u ₇₁第三最有可能等等。使用这种类型的信息可以确定机器接下来应该请求下载的是什么单元，假设执行下载的资源另外未被使用。（如果用户正在请求使用当前不在机器上的特定程序部分，那么接下来下载该程序部分是有意义的，这是因为关于用户接下来希望使用什么的任何统计“预测”将有效地被用户接下来想要什么的实际知识所取代。）

具有可用下载带宽的系统可以选择使用该带宽来下载那些在机器上具有高的存在价值的单元。在确定如何评价各种不同选择的过程中，一个考虑因素是请求有很高概率在不久的将来会被用户使用的单元，这是因为使得此类单元在用户请求之前在用户机器上可用避免了用户必须等待下载这些单元，由此增强用户体验。但是，在决定下载什么时还存在其他的评价考虑因素。一个这样的考虑因素是与小单元相比，下载大单元的价值可能相对较高。由于与小单元相比，大单元耗费更长的时间来“按需”下载，因此，与未使小单元可用的成本相比，在用户请求之前未使大单元可用的成本更大（这是因为小单元可以在请求时以相当快的速度下载）。另一个考虑因素是以深度优先还是广度优先遍历方式来下载单元。换句话说，如果系统已经下载了最有可能遵循当前历史的单元（将这个单元称为“单元A”），那么系统必须决定要被请求的下一个单元是第二最可能遵循当前历史（广度优先）的单元，还是最有可能跟随在单元A之后（深度优先）的单元。一般地，如果非常确信接下来最有可能发生的单元接下来将实际发生，那么深度优先遍历将会是有意义的。举个例子，如果若干个单元接下来将被使用的可能性是大致相同的（假设概率是0.35，0.34以及0.31），那么接下来将会发生的可能性最高的单元（即单元A）接下来实际发生的机会只有35%，因此，进行广度优先遍历可能是有意义的。另一方面，如果单元A不但接下来发生的可能性最高，而且还具有客观来说很高的概率（例如90%），那么可能有意义的是假设该单元实际接下来将被请求，然后将资源专用于下载跟随在单元A之后的可能性最高的单元，而不是尝试下载在单元A实际并非下一个单元的稀有情况中被使用的具有第二和第三最高概率的单元。可以定义成本曲线，其指示针对任何给定判定点，深度优先还是广度优先遍历将提供较高的值。

现在转到附图，图1显示的是接收流传输软件的示例过程。在转到图1的描述之前，应该指出的是，这里包含的流程图（在图1和图2中）显示的是按照用连接方框的线指示的特定顺序实现的过程的阶段的示例，但是在这些图中显示的各种不同阶段可以按照任何顺序或以任何组合或子组合方式执行。

在102处，软件包的初始部分被加载。举个例子，如果该程序是游戏，那么该程序的初始部分可以包括程序主循环（其提供游戏玩家的基本导航的机制）以及实现游戏中的初始场景的组件。如果程序是某种其他类型的程序（例如文字处理器，电子表格等等），那么程序的初始部分可以包括程序的主循环，以及实现“欢迎屏幕”的组件或实现“打开文件”功能的组件、允许编辑空白文档的组件等等。什么构成了程序“初始”部分可以由程序的性质确定。加载程序的初始部分——乃至为初始部分的构成做出任何类型的许可。由此，在102处执行的动作（与这里描述的其他操作相似）是可选的。从这一点，所述流传输过程继续确定接下来下载什么。

在104处，确定是否正在请求但尚未下载程序的特定部分。例如在游戏中，用户可能请求向左移动，而实现向左场景的组件可能尚未下载。在这种情况下，软件流传输平台实际正经历对所述程序的特定部分的直接请求。如果出现这种请求，则所述过程继续进行至106，在106中可以中断任何现有的下载过程。（可能的情况是：在预测到未来将被请求的程序部分时，所述过程已经开始下载程序的该部分。由于该过程现在具有用户想要该程序的其他某个部分的信息，因此，为了使用户不必等待过长时间，任何这种预测性下载都可以被中断，使得该过程可以下载用户实际想要的程序部分）。如上所述，“单元”实际可以包含若干个可以单独下载的块，由此，中断当前下载可以仅仅涉及等待当前的块完成下载，然后不下载单元中的附加块，使得可以处理用户请求（这些块也可以是可中断的，由此可以在不等待当前的块完成下载的情况下处理用户请求）。在108处，所请求的程序部分被下载。这时，该过程可以恢复下载被中断以适应用户请求的任何单元。然而，由于对特定单元的用户请求有效改变了当前历史，由此（有可能）使得某些其他单元更有可能跟随在当前单元之后，因此，该过程还可以选择不去恢复下载其工作于其上的单元。这时，该过程可以返回到104，以确定程序的任何附加部分是否正被请求。

如果在104处确定程序的特定部分没有被请求，那么图1所示的过程进入预期或预测模式，由此下载那些将会降低未来下载的预期成本的程序部分。从可以将在请求了程序部分之后必须等待要下载的所述部分视为“成本”的意义上讲，所要下载的内容的选择设法降低预期的未来等待。

由此，该过程继续至110，以便识别接下来下载什么。在确定接下来下载什么的过程中可以涉及各种不同的考虑因素。一个这样的考虑因素是使用的可能性（方框112）——即接下来有可能使用什么程序单元。另一个考虑因素是下载单元的大小（方框114）。如上所述，与小单元相比，大单元会耗费更长的时间等待，由此不下载较大单元的成本（或者与此相反，下载较大单元的价值）要大于不下载较小单元的成本。因此，在所有其他条件全都相同的情况下，该过程可以选择下载较大的单元，而不是较小的单元。另一个考虑因素是广度优先/深度优先选择（方框116），该选择是在已经下载了接下来最有可能发生的单元的时候出现的。如上所述，如果已经下载了该单元，那么该过程必须选择是下载接下来最有可能的单元（广度优先）还是下载最有可能跟随在刚被下载单元之后的单元（深度优先）。除了方框112-116之外，该过程可以在决定接下来下载什么的过程中使用其他成本/价值考虑因素（方框118）。

在做出了关于下载什么的决定之后，该过程继续至120，以便下载所选择的单元。然后，在122处可以保存所下载的软件单元，其中保存软件单元的动作可以在用户实际请求使用该单元之前发生，由此使得所述软件单元在用户未来的确请求使用该单元的情况下易于得到。然后，该过程返回到104，以便主动选择另一个单元（方框110以及下列等等）或在当前提出了这种请求的情况下下载专门请求的程序部分（方框106以及下列等等）。

图1的过程假设的是已经做出了关于特定单元将遵循给定历史的可能性的某种评定。图2显示的是识别哪一个程序单元有可能遵循给定历史的示例过程。图2的过程结果是可被提供给程序在其上使用的客户端的表格，使得这些客户端可以确定接下来请求哪一个程序单元。

在202处，生成块的预测图表。换言之，假设将被流传输的程序已分成了块，这其中的每一个块用图表中的节点表示。然后，基于块被请求的序列的历史分析，第二个块跟随在第一个块之后的任何情形对应于从第一个块到第二个块的定向边线（directed edge）。这个定向边线是用数字标记的，该数字表示目标（第二个）块跟随在特定序列之后的总的次数除以发生该序列的总的次数。这个数字表示特定块将处于某个特定块（更一般地，特定序列）之前的概率。这种图表的一个示例是图3显示的图表300。

可以看出的是，图表300具有用A-H标记的8个节点，其中每一个节点表示将被流传输的软件的块。当观察到在一个块之后请求了另一个块的历史时，这种关系是用定向的带标记边线表示的。例如，从A到B的定向边线表示这样一种思想：在过去的某个点，块B是在块A之后直接被请求的，并且有60%的时间在请求了块A之后接下来的块是块B。此外还存在从A到C的边线，其指示块C是在块A之后也已直接被请求；但在块A已被请求的所有的情形中，紧跟着的块是块C的情形只占到了40%。图表300中的其他边线表示各种序列发生的概率。注意到图表300表示大小为1的历史——即，为了确定特定块将跟随在块“序列”之后的概率的目的，图表300假设该序列的相关长度是单个块。然而应该理解，可以具有不同的历史大小。因此，如果历史大小为2，那么举例来说，取代图表中的标签指示G跟随在D之后的可能性有多大，它们将指示G跟随在B-D之后的可能性有多大以及G跟随在C-D之后的可能性有多大。此外，虽然图表300被显示成是在节点F、G和H终止的定向非循环图表，但是应该理解，节点F、G和H可以具有图中并未显示的子节点（如椭圆所示），并且图表实际可以具有循环（例如，如果存在序列A-B-D-A，那么该序列将会表示图表中的循环）。

图4显示的是图3的图表的表格表示400。该表格中的每一个单元格表示用边线连接的一对节点。行标签402标识边线开始的节点，而列标签404指示边线结束的节点。每一个单元格中的值都是在给定（作为历史）行标签中的节点已被到达的情况下到达列标签中的节点的概率——即，单元格中的值对应于图3中的带标签边线上的标签。（对于不存在的边线来说，单元格的值是0，由此指示在没有从第一节点到第二节点的边线的情况下，从第一节点变换到第二节点的概率为零）。由此，如在图3的图表中看到的那样，如果请求了块A，那么块B将是下一个要被请求的块的概率是60%。因此，在图4中，行标签是A并且列标签是B的单元格具有值0.6。（如上所述，在图3中没有显示任何可以从节点F、G和H到达的节点；因此，在表格表示400中，行F、G和H保持空白）。虽然可能很容易使用图形或表格表示来显示大小为1的历史，但是应该了解，在表格表示中更容易显示大于1的历史大小。举个例子，如果我们使用的历史大小是3，那么表格的每一行可以是三个块的序列，由此导致用A-B-D、A-C-D、B-D-H等等标记的行。如果历史大小是3，那么列标签仍旧可以是单个块，使得每一个单元格都会指示在给定特定的三个块的历史的情况下到达给定块的概率。

现在回到图2，接下来的动作可以是使用块的预测图表来生成组块的预测图表（方框204）。如可以从早先的论述中回顾，组块是被确定成有足够概率在一起发生的块的序列。识别组块基于对于图表中表示的块的分析以及图表中的边线（或是该图表的表格表示中的单元格）所表示的概率。为了识别组块，可以选择阈值，然后，只要到达下一个块的概率大于或等于该阈值，则可以将块添加到组块中。举个例子，假设将阈值设定在0.9。然后，参考图3的图表300（或图4的其表格表示400）可以看出，在B之后将直接请求D的概率是0.9，因此，从B到D的变换满足该阈值。由此，B和D可以一起组合成单个组块。然而，不存在从节点D到达的概率大于90%的特定节点，因此不在组块中添加附加节点。由此，最终得到的组块是B-D。在实践中，以这种方式识别组块简化了用以确定接下来将要下载什么的表格。理论上，这样做导致一些精确性方面的损失；毕竟，参考图3的图表，在B之后下载C是可能的，因此，如果将B和D视为一个组块，那么只要下载B就会下载D（有可能是不必要地）。但是，由于序列B-D要比B-C更有可能发生，因此，在确定下载什么的过程中得到的简化有可能会弥补可能因为精确性损失而导致的任何损害。这种弥补归因于立刻下载较大分段的价值——其减小了向服务器提出多个请求的网络开销，而不是一个更大的请求。

在图5中可以看到（以表格形式）所得到的将每一个组块视为单个节点的图表500。在图表500中，序列B-D（它是一个组块）缩写（collapse）成单个元素X。由此，在行标签和列标签中是没有B和D的，这是因为——在将B和D一起组合成组块的情况下——为了确定请求下载的元素序列，B和D不被视为单独的单元。（如上所述，在如果必须中断组块的下载、可以通过仅仅请求那些处于组块中、在中断前未被下载的块来恢复组块下载的意义上讲，构成组块的单独的块可能仍旧是可单独请求的）。

回到图2，在206处，可以基于预测图表生成预测列表。（将块一起组合成组块可以被视为可选地操作，由此可以基于以组块为基础的图表或以块为基础的图表生成预测列表）。该预测列表指示了在给定特定历史的情况下的下一个最有可能的单元（块、组块或其他）。图6显示的是示例预测列表600，该列表是基于图5的以组块为基础的图表500的。

使用图5的图表500中的数据，可以针对图表中给定的节点确定哪一个节点最有可能（或者第二最可能、第三最可能等等）跟随在该节点之后。应该指出的是，在图5的示例中，历史的大小是1，由此历史是由单个节点定义的，但是该历史的大小也可以大于1。如果历史大小大于1，那么图表中的每一行都会用多节点历史标记，由此图表中的每一个单元格将会指示哪一个节点最有可能跟随在特定的多节点序列之后。（举例来说，如果历史大小是3，那么A-B-D将会是针对行的示例标签。A-B-D行中的每一个单元格将会指示跟随在序列A-B-D之后的第一[或第二或第三等等]最可能的节点）。

在图6的示例中可以看出，X（包含B-D组合的组块）是最有可能跟随在A之后的节点。由此，预测列表600将X包含在针对行A的“第一最可能”列中。由于——如果X没有跟随在A之后——则C是下一个最有可能跟随在A之后的节点，因此，预测列表600还将C包含在针对行B的“第二最可能”列中。关于哪一个节点是最有可能、第二最有可能等等跟随在给定节点之后的确定可以通过从（图5的）图表500中的单元格中读取数值来做出。例如，在用X标记的图表500的行中，节点F的值是0.5，节点G的值是0.3，以及节点H的值是0.2。由此，F是第一最有可能跟随在X之后，G是第二最可能，并且H是第三最可能。这些事实在图6的预测列表600中得到了反映。

如上所述，图表中的“节点”表示特定组块或块（例如“单元”）。同样如上所述，关于接下来下载哪一个单元的评定可以基于哪一个单元具有最高的下载值。如上所述，所述评定可以基于一些因素来做出，例如单元中的数据量、单元不久的将来将被使用的可能性、广度优先/深度优先考虑因素以及其他评估因素。由此，如果必须按需下载大单元，那么由于等待该单元所耗费的时间很长，因此，下载大单元的值会很高。此外，下载被请求概率很高的单元具有很高的值，这是因为有可能这样做将通过避免未来的等待而得到报偿。至于广度优先/深度优先考虑因素，在下载了接下来最有可能被请求的单元之后，将会存在关于下载接下来最有可能被请求的单元（广度优先）还是假设最有可能的单元实际是正确的猜测并且随后下载最可能跟随在该单元之后的单元（深度优先）的问题。该决定取决于实际将会下载接下来最有可能的单元的确定性。将深度优先与广度优先相比较来进行选择的值可以用成本函数来表示。

基于这些考虑因素，在下文中描述了用于选择所要下载的下一个单元的示例过程。首先，系统可以以客户机最后提取的组块（或其他单元）为开始，出于讨论的目的，所述组块将被称为C。假设函数P(C,N)是预测列表中跟随在C之后第N个最可能的元素。举个例子，参考图6，由于X是第一最有可能跟随在A之后的组块，因此P(A,1)=X。假设BF(N)是广度优先遍历的成本，所述成本是在包含C的预测列表的相同的行中选择节点的成本。即，它是通过选择P(C,N+1)、P(C,N+2)等等来选取下一个节点的成本。此外，假设DF(N)是深度优先遍历的成本，所述成本是在假设当前P(C,1)（或更概括的说是P(C,N)）的猜测正确的情况下选择接下来“最有可能的”节点的成本——即，它是选取P(P(C,N),1),P(P(P(C,N),1),1)等等的成本。在所有其他条件相同的情况下，如果深度优先选择的成本大于广度优先选择的成本，那么选择广度优先策略；否则，选择深度优先策略。

一种策略可以组合深度优先和广度优先搜索。例如，可以基于广度优先策略来选择所要下载的第一个单元，然后基于深度优先策略来选择接下来将要下载的单元，以此类推。一般地，特定选择的成本等于策略成本（由BF或DF函数指示）乘以所要下载的组块大小。

图7显示的是可以部署这里描述的主题的方面的示例环境。

计算机700包括一个或多个处理器702以及一个或多个数据记忆组件704。处理器702典型地是微处理器，例如在个人台式计算机或膝上计算机、服务器、手持计算机、或别的类型的计算设备中找到的微处理器。数据记忆组件704是能够短期或长期存储数据的组件。数据记忆组件704的示例包括硬盘、可移除盘（包括光盘和磁盘）、易失和非易失随机存取存储器（RAM）、只读存储器（ROM）、闪存、磁带等等。数据记忆组件是计算机可读存储媒体的示例。计算机700可以包括或者关联于显示器712，该显示器可以是阴极射线管（CRT）监视器、液晶显示器（LCD）监视器或是其他任何类型的监视器。

软件可以保存在数据记忆组件704中，并且可以在一个或多个处理器702上执行。这些软件的一个示例是流传输软件706，该软件可以实现在上文中结合图1-6描述的某些或所有功能，但是任何类型的软件都是可以使用的。举例来说，软件706可以通过一个或多个组件来实现，其中所述组件可以是分布系统中的组件、单独的文件、单独的函数、单独的对象、单独的代码行等等。将程序存储在硬盘上、加载到RAM中以及在计算机处理器上执行程序的计算机（例如个人计算机、服务器计算机、手持计算机等等）代表了图7描述的场景，但是这里描述的主题并不局限于这个示例。

这里描述的主题可以作为在一个或多个数据记忆组件704中存储并在一个或多个处理器702上执行的软件来实现。作为另一个示例，本主题可以实现为存储在一个或多个计算机可读存储介质中的指令。诸如光盘或磁盘之类的有形介质是存储介质的示例。这些指令可以存在于非临时介质上。在由计算机或其他机器执行时，这些指令可以使计算机或其他机器执行方法的一个或多个动作。执行这些动作的指令可以存储在一个介质上，或者可以分布在多个介质上，使得这些指令可以集中出现在一个或多个计算机可读存储介质上，而不用考虑所有这些指令是否正好是在相同的介质上。应该指出的是，在“存储”信号的介质（可被称为“存储介质”）与——作为对比——包含或传输传播信号的介质之间是存在区别的。DVD、闪存、磁盘等等是存储介质的示例。另一方面，信号短时存在的导线或光纤是暂时信号介质的示例。

此外，这里描述的任何动作（无论是否在图中显示）都可以作为方法的一部分由处理器（例如一个或多个处理器702）执行。由此，如果在这里描述了动作A、B和C，那么可以执行一种包含了动作A、B和C的方法。此外，如果在这里描述的是动作A、B和C，那么可以执行一种方法，该方法包括使用处理器来执行动作A、B和C。

在一个示例环境中，计算机700可以通过网络708通信地连接到一个或多个其他设备。在结构上与计算机700相似的计算机710是可以连接到计算机700的设备的示例，但是其他类型的设备也可以如此连接。

虽然以特定于结构特征和/或方法动作的语言描述了本主题，但是应该理解，所附权利要求中限定的主题不必局限于上述特定特征或动作。相反，以上描述的特定特征和动作是作为实现权利要求的示例形式公开的。

Claims

1.一种使用流传输软件的方法，该方法包括：

接收表格（600），该表格针对给定的使用历史指示接下来有可能被请求的软件单元（112）；

确定（104）用于将所述软件从远程位置（710）传送到所述计算机（700）的资源未被使用；

使用所述表格（600）来选择要被请求的软件的第一单元，所述第一单元是基于下载所述第一单元的值（118）选择的；

从所述远程位置（710）请求（120）软件的所述第一单元；

接收（120）软件的所述第一单元；以及

在接收到使用软件的所述第一单元的请求之前，存储（122）软件的所述第一单元。

2.权利要求1的方法，其中所述软件被分成块，其中每一个单元都是一个所述块，并且其中该方法还包括：

将所述块组合成组块，其中每一个组块都是在序列中出现的可能性超出阈值的一个或多个块的集合；

其中每一个单元都是一个所述组块。

3.权利要求1的方法，还包括：

基于所述单元的大小来确定所述值，其中与较小的单元相比，较大的单元具有较高的值。

4.权利要求1的方法，还包括：

基于所述单元的深度优先遍历还是广度优先遍历具有更高的成本来确定所述值。

5.权利要求1的方法，还包括：

在接收到软件的所述第一单元时，接收对软件的第二单元的请求；

中断软件的所述第一单元的下载；以及

使用所述资源来下载软件的所述第二单元。

6.一种计算机可读介质，具有执行权利要求1-5中任一权利要求的方法的计算机可执行指令。

7.一种使用流传输软件的系统，该系统包括：

存储器（704）；

处理器（702）；以及

存储在所述存储器（705）中并且在所述处理器（702）上执行的组件（706），其中所述组件（706）接收表格（600），该表格针对给定的使用历史指示接下来软件的哪些单元有可能被请求（112），其确定（104）用于将所述软件从远离所述系统（700）的位置（710）传送到所述计算机（700）的资源是否正被使用，使用所述表格（600）来选择（110）要被请求的软件的第一单元，所述第一单元是基于下载所述第一单元的值（118）来选择（110）的，从所述远程位置请求（120）软件的所述第一单元，接收软件的所述第一单元，以及在接收到使用软件的所述第一单元的请求之前存储（122）软件的所述第一单元。

8.权利要求7的系统，其中所述软件被分成块，其中每一个单元都是一个所述块，其中所述块被组合成组块，其中每一个组块都是在序列中出现的可能性超出阈值的一个或多个块的集合，以及其中每个单元都是一个所述组块。

9.权利要求7的系统，其中所述组件基于所述单元的深度优先遍历还是广度优先遍历具有更高的成本来确定所述值。

10.权利要求7的系统，其中当软件的所述第一单元被接收到时，所述组件接收对软件的第二单元的请求，中断软件的所述第一单元的下载，以及使用所述资源来下载软件的所述第二单元。