CN102857534B - 一种基于云计算的远程交互方法 - Google Patents

Abstract

本发明涉及一种基于云计算的远程交互方法，在交互方的一端，接收鼠标指针移动信息的矩形区域被分割为两部分，包括正常区域与缓冲边缘区域；在正常区域内，鼠标移动的信息被正常地发送到远程的应用程序；当鼠标指针移动到矩形边缘范围的缓冲边缘区域内时，在接收到下一次鼠标移动指令之前，最后一次移动的信息以一定间隔被反复发送到交互方的另一端，使得用户使用鼠标发送向特定方向持续移动的信息；在缓冲边缘区域时，特定的图案将显示在鼠标指针焦点位置附近，以提示用户一个特殊的移动行为正在发生。本发明不仅能降低硬件资源的成本，同时可实现多方交互。

Description

一种基于云计算的远程交互方法

技术领域

本发明涉及一种基于云计算的远程交互方法，涉及计算机、网络、流媒体等多个技术领域。

背景技术

云计算指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。云计算（Cloud Computing）是网格计算（Grid Computing ）、分布式计算（DistributedComputing）、并行计算（Parallel Computing）、效用计算（Utility Computing）、网络存储（Network Storage Technologies）、虚拟化（Virtualization）、负载均衡（Load Balance）等传统计算机和网络技术发展融合的产物。

在云计算系统中执行交互式程序的一个问题在于，交互式程序可能被设计为仅被用户在其所运行的计算机上通过本地交互设备来进行交互。亦即用户的交互行动依赖于本地计算机上的交互设备（如键盘，鼠标，显示器等）。这意味着在特定的时刻，云系统中一个计算节点最多只能为单个用户提供服务。

对大规模的云计算系统而言，其总建设成本和单计算节点的成本密切相关。通常地，如附图1所示，硬件设备的性能/价格比在一定范围内随着性能的提高而增加，同时，较高的性能也有助于计算节点能承受程序更严格的性能要求。然而高性能同时也意味着成本的提高，并存在两个问题：1.对于交互式行为的应用程序的计算节点而言，通常程序对节点的计算能力的使用在时间上是不平均的。例如在一个三维建模的应用中，用户输入数据的过程（低计算资源占用）可能占到使用时间的大部分而渲染过程（高计算资源占用）只占短时间，因此多数时间内计算资源被闲置；2. 交互式应用程序的计算资源使用实际达不到硬件性能的上限，这在交互式PC游戏中尤其明显。由于PC游戏往往设计成在达到一定的用户体验要求时只需消耗一定限度的计算资源，并且往往为了适应较多不同型号硬件设备而限制资源的消耗。

因此在现有的云计算服务体系中，交互式PC游戏的用户体验被限制在一定的水平上，因此也就限制的硬件资源的消耗，最终的结果是，购置更多计算资源所付出的硬件设备成本被浪费。

除此之外，单个计算节点还具有额外的固定成本，例如总线设备（主板），存储设备，电源和外壳，以及为了放置计算节点的空间成本等。可以看到，当云计算系统每个用户的服务成本和计算节点的成本相关时，通过减少单计算节点的硬件成本的方法能降低的用户服务成本是非常有限的。

显然地，有效地下降单用户成本的方案是使单个计算节点可以同时为多个用户服务。但如前所述，交互式应用程序需要独占计算节点上的交互设备来运行。虚拟化（Virtualization）技术提供了一个可能的实现方式。然而，虚拟化的问题是，使用这一技术将带来额外的硬件资源的开销，特别是图形处理器（GPU）的性能往往会遭到显著的损失，并存在硬件支持上的缺陷。对于以提供windows应用程序为主的云计算服务系统而言，虚拟化技术将增加计算节点上运行的windows操作系统数量进而提高授权费用；虚拟化技术本身和windows操作系统的结合也并不非常成熟。

发明内容

为了解决上述技术问题，本发明提供一种基于云计算的远程交互方法，包括以下步骤：

在交互方的一端，接收鼠标指针移动信息的矩形区域被分割为两部分，包括正常区域与缓冲边缘区域；在正常区域内，鼠标移动的信息被正常地发送到远程的应用程序；当鼠标指针移动到矩形边缘范围的缓冲边缘区域内时，在接收到下一次鼠标移动指令之前，最后一次移动的信息以一定间隔被反复发送到交互方的另一端，使得用户使用鼠标发送向特定方向持续移动的信息；在缓冲边缘区域时，特定的图案将显示在鼠标指针焦点位置附近，以提示用户一个特殊的移动行为正在发生。

所述交互方的一端通过一安全网关将数据发送至所述交互方的另一端，所述安全网关包括一个或多个服务节点；所述服务节点进一步包括一处理单元，介于应用程序与系统API或者网络之间，包括一个函数地址监测模块，用于检测内存中应用程序的函数地址，以及一个函数地址重定向模块，用于改变应用程序的内存中存储的函数地址，对函数地址进行重定向；以及多个接口，用于与实现与计算机硬件以及API之间的通信。

所述交互方为计算机、或电视机顶盒、或移动终端设备。

所述服务节点将共同访问同一个存储节点上的数据，并将每个用户所产生的额外数据存储到单一的存储节点上。

所述多个服务节点构成一个节点阵列，多个节点阵列共享一个存储节点读取数据和记录用户生成的数据，用户通过网络延时和带宽等数据选择所述多个节点阵列中的一个。

附图说明

图1是大规模云计算系统的硬件设备的性能/价格比例示意图；

图2是基于云计算节点的远程交互式系统的架构；

图3是基于云计算节点的远程交互式系统的模块图；

图4是基于云计算节点的远程交互式系统的层次图 ；

图5是微环境的一种实施方式的示意图；

图6是微环境下重定向示意图 ；

图7是本发明中鼠标信息交互示意图 ；

图8是本发明中对画面进行流水线处理的示意图 ；

图9是云计算节点的远程交互式系统访问网络文件的示意图 ；

图10是交互信息在不同用户之间分发的示意图 ；

图11是本发明关于视频编解码的示意图 ；

图12是本发明“展示墙”的示意图 ；

图13是本发明对有限的矩形范围内接收的鼠标操作的处理方式的示意图 ；

图14是使用云计算远程交互程序服务的用户所执行的工作流程图；

图15是分布式的计算服务节点阵列的部署图。

具体实施方式

图2和图3列出了一个基于云计算节点的远程交互式系统的架构。其包括终端设备，web前端、安全网关。所述终端设备可以是PC，移动终端或者电视机顶盒等任何计算能力足够胜任解码标清或高清H.264视频流的设备。所述安全网关包括一个或多个服务节点，终端设备首先访问云计算的系统的前端，通过验证后取得连接安全网关内某一服务节点的权限；设备随后使用这一权限和云计算系统内特定的服务节点连接。

通过一个特定的由硬件、软件，或其结合来实现的平台或环境（下面简称“微环境”）来实现上述功能，以windows操作系统为例，可以为其它的windows应用程序虚拟其对用户交互系统的使用，从而使单个运行windows操作系统的计算节点可以同时服务于多个用户。相对于其他方案，微环境有下列优势：

微环境使得多个用户同时利用计算节点的资源（包括单个操作系统本身的软件资源在内）成为可能。

被执行的应用程序以几乎原生的方式访问硬件资源（特别是图形处理器资源）。

微环境并不改变所执行的应用程序的二进制代码。

本发明中，在服务节点内，一个微环境为用户启动指定的应用服务，所述服务可以包括应用程序在内的所有服务，应用程序的界面和音频输出通过微环境转换为视频和音频流，以及一个（可选的）数据量很小的附加信息流通过互联网传递给终端。用户在使用终端设备上接收到上述视频和音频流以及（可选的）附加信息流后，通过设备的交互硬件（键盘，鼠标，遥控器，游戏控制器等）发送控制数据到计算服务节点的微环境，微环境将此控制数据作为所运行的应用程序接收的用户交互数据。从而完成了一个交互的过程。

微环境的实现在操作系统层次，介于应用程序与系统API或者网络之间，本领域的技术人员应当理解，虽然这里使用了“微环境”这一术语，但是应当将其扩展地理解为能够由硬件、软件来实现的一个功能结构体，或者一个处理单元。考虑一个任意的应用程序，为了和计算机上的硬件交互设备进行交互，应用程序必须通过操作系统提供的接口访问硬件驱动，进而控制硬件。（如图4左方）微环境包括一个函数地址监测模块，用于检测内存中应用程序的函数地址变量，以及一个函数地址重定向模块，用于改变应用程序的内存中存储的函数地址变量，以及一个地址保存模块，用于保存重新被定向的函数地址；以及包含多个接口，用于与实现与计算机硬件以及windows应用程序接口之间的通信，例如程序界面，画面渲染，音频输出和控制信息（键盘，鼠标等信息）的输入。

通过改变应用程序的内存中存储的函数地址变量，使应用程序对操作系统接口的访问重定向到微环境提供的接口而不再和实际的PC系统的硬件层或硬件驱动接触（如图4右方）。对于应用程序而言，微环境提供了和操作系统相同的接口和响应行为。因此在微环境中执行并不会影响其正常的工作流程。而微环境则获得了应用程序和用户的交互数据，包括程序界面，画面渲染，音频输出和控制信息（键盘，鼠标等信息）的输入。微环境可以在云计算系统所实现，并和视频/音频压缩模块和网络模块相连接，从而将应用程序的界面和渲染数据转换成视频/音频流，经网络模块传送到互联网上的其它终端（云计算服务的用户）。同样，终端的用户交互信息通过互联网到达微环境后，代替了原来由计算节点上的交互设备所发送的用户交互信息传达给应用程序，最终实现通过互联网在远程计算机（云计算服务节点）上执行交互式应用程序的目的。

图5显示了微环境的另一种通用的实施方式。以windows操作系统为例，微环境的实现机制结合windows系统特有的动态链接库（DLL）工作模式和独立的进程空间机制。在操作系统中，微环境可进一步包含多个进程，所述进程和客户端连接，由客户端请求执行特定的请求，所述请求可以是应用程序或者发送或者接收的数据。微环境随后将上述请求载入内存，在上述请求实际执行之前，微环境利用动态链接库的工作方式将重定向模块（以DLL的形式）加载进应用程序的进程空间，并在应用程序进程的内存空间中修改应用程序已载入的执行代码。或者为了节省PC机硬件的资源，微环境直接利用自身的重定向硬件模块修改上述请求中所包含的函数地址变量，以改变函数的操作系统应用程序接口API的功能调用入口位置。当应用程序执行之后，程序调用操作系统API时，重定向模块将被修改的函数地址跳转到重定向模块所存储的函数地址。重定向模块和在其它进程中运行的微环境主体通过特定的通讯隧道连接，将程序执行时的交互式内容输出到微环境进程中，经过处理后最终通过网络发送到客户端。

图6显示了应用程序进程的内存空间中系统API经过修改后被调用时的典型工作流程：通过修改内存数据，API入口函数最开头的机器指令被修改为一条跳转指令，跳转到微环境加载的重定向模块所提供的接口函数入口。从而使应用程序对系统API的使用首先被重定向到微环境重定向模块中。微环境的接口函数接收了应用程序调用系统API时的所有参数，此后可以使用下述方式之一获取应用程序的交互信息：

1）应用程序调用系统API时传入的参数就包含了所需的交互信息，例如对鼠标指针的定位，文件访问的路径参数等。

2）微环境使用获得的参数，代替应用程序调用其原本所需调用的系统API。如图5所示，微环境中可以首先执行原API中被修改部分的内存的指令，再从原API中内存被修改部分之后开始执行直到API函数结束，即完成一个API的调用过程，并从API调用后返回的结果数据中取得应用程序的交互信息，例如被渲染的程序界面画面等。这些信息微环境接口函数结束，交还给应用程序前，可以首先被输出到微环境的导出模块。

3）应用程序对系统API的使用往往和硬件设备有关，特定的硬件（或硬件驱动）可以由微环境实现并直接和导出模块连接。通过修改API调用的参数，微环境可以将应用程序对某个硬件设备的访问转交给此和导出模块连接的特定的硬件（或驱动）进行，从而得到应用程序从硬件设备中输出的信息。例如音频信息的导出。微环境将应用程序对硬件访问重定向的功能还具有更多的作用，将在后面阐述。

微环境的导入模块工作流程和导出模块类似：微环境接口函数从导入模块中得到需要的信息，通过应用程序调用API时传入的参数或返回值等传递给应用程序。

进一步参见附图3，在微环境中，交互所包含的所有信息被分别处理，并最终通过不同的信息流，传送到客户端程序，在该实施方式中，微环境包括但不限于以下模块：声音导出模块、界面导出模块、其他信息导出模块、以及输入导入模块。以PC游戏为例，游戏的画面被界面导出模块转换为视频流输出，背景音乐和效果音声音导出模块转换为音频流输出。此外为了实现用户交互的功能，一些额外的信息例如应用程序中光标的位置和样式等也被信息导出模块从一个独立的信息流通道输出。在用户客户端接收到的交互信息则被传送到输入导入模块，并转换为应用程序实际获得的鼠标和键盘消息等内容。

更进一步，微环境重定向模块包含一系列操作系统调用的接口，包括但不限于以下类型：

图形显示接口，包括Windows GDI和DirectX。在最近几年中，绝大部分的PC游戏利用DirectX接口渲染其执行过程中全部的画面。

音频播放接口，例如DirectSound或者即windows媒体设备接口（Multimedia Device API）。

输入/输出接口，包括Direct Input和键盘/鼠标消息接口。

存储和应用程序上下文接口，包括文件访问API，注册表访问API，环境变量和内核对象等。微环境重定向的这些接口使多个相同的应用程序在同一操作系统下执行时可以避免资源使用的冲突问题。微环境还可以记录单元，用于记录和保留这些上下文信息，从而为应用程序下一次从当前上下文信息执行作准备。

由于微环境可以代替应用程序进行系统API的调用。因此当应用程序需要使用硬件资源时，微环境并不需要模拟所有的硬件响应。在实际的系统中，微环境中各导出模块对应用程序的请求在进行必要的处理后，通常都会将应用程序对硬件资源（通过实际的系统函数接口）的访问定向回原有的位置来。实际上应用程序在微环境内和原来的工作方式相比，只多出两步跳转指令和微环境中所需的额外的操作，这和虚拟化技术相比具有少得多的开销，可以认为非常接近于原生的工作方式。

虽然Windows操作系统已经可以支持多组硬件资源同时工作，例如多核心的CPU和多GPU。但操作系统对资源的自动调度仍局限于CPU上，而并不会自动调度和分配其它硬件（特别是GPU）的计算能力。例如即使计算节点上部署多个GPU，一般的应用程序往往只使用操作系统中被指定为“主GPU”的设备进行3D画面的渲染。即使应用程序可以访问到全部GPU设备的信息并且能通过用户的指令选择某个GPU设备，当计算节点上运行多个应用程序时，对每个用户而言，选择适当的GPU设备也是不可能的。

利用微环境界面导出模块对DirectX接口的重定向，微环境可以在多个计算节点（或服务节点）的多个GPU设备间为某个特定的应用程序分配合适的GPU资源。即选择当前具有足够的空闲计算能力的GPU设备，并对这些GPU设备赋予不同的资源占用来完成一特定计算。为此，微环境中进一步包含一记录模块，用于记录当前在其中执行的所有应用程序对GPU资源的使用情况，进一步，其还包含一监视模块，用于监视GPU的工作状态，以便为下一个执行的应用程序分配适合的GPU设备，也就是说，每一计算节点（或服务节点）的GPU都可能被分配参与与该计算节点无关的计算，所述监视模块的一个实施方式是基于读取标准的系统接口和驱动接口的实时参数来监视其工作状态。

声音导出模块对应用程序音频的重定向输出实现于硬件驱动层面。微环境在介入前已以硬件驱动的形式实现多个（虚拟的）音频渲染和播放设备。应用程序对音频播放接口的调用由虚拟设备实现后压缩为音频流通过互联网输出到远程用户的计算机。在正常情况下，多个应用程序同时运行时，每个程序的音频输出将被混合并同时输出于系统的音频设备。另一方面，微环境可以为其中每个执行的应用程序分配这些虚拟音频设备的其中之一，使不同应用程序的音频输出得以成为独立的音频流并通过不同微环境的音频通道进行传送。

在画面和音频内容之外，应用程序为了和用户正确地交互所需的其它信息也由其它信息导出模块所收集并通过辅助通道传送到客户端。例如，当前应用程序中鼠标指针的实际位置需要传送到客户端，以便在客户端屏幕上准确地显示其的位置和其它信息。

鼠标指针是交互式的windows程序中最为常见的元素。从图7可以看到，在和远程的应用程序交互时，任何对鼠标指针的交互操作都需要通过网络传输得到，响应后才能显示回用户客户端。这意味着用户在客户端移动鼠标指针时，将观察到一个和网络延时（TTL）相当的延迟。我们观察到，用户对移动鼠标指针的延迟是非常敏感的；但相对地，在点击屏幕上特定元素时，用户的对延迟的容忍度则大得多。因此，微环境中并不直接将光标的信息合并到程序界面内作为视频信息流来传输。而是通过辅助信息流传送鼠标指针的信息并在客户端直接绘制出来。当用户移动鼠标指针时，客户端本地将首先响应鼠标移动的事件并重画鼠标指针，并同时将此事件通过控制信息传送到远程执行的应用程序。这一次策略消除了移动鼠标指针时可觉察的延迟。网络延时导致的延迟仅发生在鼠标指针的移动导致程序界面发生特定的响应的过程中。而如前述，这一延迟能为多数用户所容忍。

指定特定的远程应用程序可能要求较高的屏幕分辨率而客户端屏幕可能无法满足此要求，这在移动终端等设备上尤为常见。在此情况下，和界面导出模块耦合的缩放模块会将应用程序的输出界面缩小到客户端屏幕可接受的范围并输出为视频流。在界面被缩小之后，界面上原有的部分元素，特别是文字内容等，可能会由于缩小而失去其可读性。此时，一个额外的应用程序将在微环境内启动，这一程序访问界面导出器的接口，将程序界面上特定位置（通常以是鼠标指针所指向的位置为中心的一个小的方形区域）的画面（保持其原有的大小）单独划出，利用视频编码器将其转换为一个较小的视频流，通过辅助信息流传输到客户端（如图7），即不在正常的视频流部分编码；正常的视频流可以用于编码整个图像。这一视频流在客户端解码后，重现模块将其以和远程应用程序上相同的分辨率显示，并叠加于客户端屏幕所显示的（已被缩小了的）程序界面画面上。用户可以通过鼠标指针的移动等操作，从此叠加的放大画面上阅读到缩小后无法识别的画面元素。客户端重现模块将单独划出的部分用原分辨率显示，而将所述呈现画面缩放至与该客户端所使用的显示设备相适应的分辨率进行显示，所述单独划出的部分至于最上层显示。

微环境的视频和音频导出模块和低延迟的编码模块相耦合。编码模块所需的运算可以利用计算服务节点上的CPU或GPU来完成，或使用专门的编码硬件进行处理。应用程序界面的图形信息按一定的时间间隔构成输出视频流的每一帧。在某一时刻，应用程序界面图形转换为视频流中对应帧的编码时间不大于10毫秒；在用户的终端设备上，这一视频帧被视频解码器解码并呈现在终端屏幕的时间也不大于10毫秒。在正常情况下，我们期望从服务系统到用户终端的网络传输延时（TTL）在40-50毫秒左右。另一方面，视频流的每秒帧率被限制在25-30之间，因此用户在和远程应用程序的交互行为所观察到的延迟最多在100毫秒左右。这对于一般的应用程序交互乃至于PC游戏都是一个可接受的范围。

图8显示了视频编码模块，解码模块和传输模块为了减少编码—解码延迟所采取的流水线策略（图中最下面的策略）。程序的画面实际被分割为多个部分，每个部分都被分别编码成一个单独的视频流传输到客户端，由解码模块解码后，再由重现模块将分割的画面拼合并显示出来，其中所述单独划分的画面以更高的带宽传输。GPU将不断改变的程序界面进行压缩编码转换为视频流，并在远程客户端解码的过程。编码—解码过程是准实时的，其延迟和数据在网络中传送导致的延迟相比是小量。为了降低编码和解码的延迟，应用程序界面在编码过程中实际被分割成多个部分，每部分独立地进行编码—传输—解码，各部分的处理步骤以流水线方式并发执行。

和将整个画面编码为单一的视频流相比（图8上方的策略），虽然在压缩率上有所损失，但可以有效地利用计算节点的并行能力，减少编码延迟（图8中间的策略）。然而，客户端的解码模块由于客户端计算能力的限制，往往并不具备并行解码能力，因此并不能显著减少解码延迟。同时也可以看到，在前面这两种策略中，设备的计算能力在传输过程中是被闲置的。而在流水线策略中，编码和解码的过程和传输的过程在不同画面块之间交错地进行，在其中一个画面块传输时，设备的计算能力得以被编码模块和解码模块用来对其它画面块进行处理，实际上将编码—传输—解码三个步骤部分地并行起来，从而减少了总的交互延迟。

微环境的视频编码模块和对应的客户端设备上的视频解码模块使用H.264或类似标准。在视频编码中必须包含两种类型的画面帧。其中之一（I帧）在解码时不依赖于任何其它画面帧，另一种（P帧）的解码则依赖于之前被接收到的某些帧的信息。单个的I帧需要比P帧大的字节数，I帧在视频流中的分布是不确定的，每两个I帧之出现之间的时间间隔在1-10秒之间。在两个I帧之间的视频流由字节数较小的P帧所组成。

在特定的时刻内为云计算系统的节点提供执行种类繁多的应用程序的可能是相当困难的。最突出的问题之一在于保存每个应用程序的二进制执行代码可能都需要大量的存储比特元。特别是对PC游戏来说，当代的PC游戏的二进制执行代码往往超过4G字节（1张标准DVD可以承载的字节数）。如果将程序的二进制代码分别保存于每个计算节点的本地存储器（硬盘）上，则需要为每个计算节点提供数TB字节的存储能力。这给的存储系统的成本和维护都带来相当多的困难。一个节约计算节点的存储空间的方案是将程序的二进制代码保存在单一的存储设备上，即如图3所示的程序存储阵列，而各节点在执行程序时通过高速的网络连接访问此设备上的代码数据。

能这一并发访问只能在基于网络文件系统（例如SAMBA）层面上而不能在网络磁盘系统（例如iSCSI）上实现。然而对很多只为在高速的本地存储器上运行而设计的应用程序（例如几乎所有的PC游戏）而言，程序在执行到和用户交互前需要预先从存储系统中读入大量的数据到内存中。从理论上说，当计算节点和存储节点之间能以千兆（Gigabit）网络的理想速度传送数据时，数据的读取速率（~100MB/s）已经能和常规的本地存储器（硬盘，约70MB/s）相匹配。数据的读取导致的等待时间如果和在本地存储器上相当（甚至略长）时，这一等待已经被用户熟悉和接受，将不会降低用户体验。然而，这些数据常常以小文件的形式存放，而windows下常用的基于SAMBA协议的网络文件系统并不适合于大量小文件的并发读取任务，结果导致实际的有效数据读取速度往往小于10MB/s，程序执行前和执行中的数据读取等待时间是在本地存储器上的数倍乃至十数倍，严重降低了用户体验。

通过微环境，我们优化了SAMBA协议下的网络文件系统在应用程序访问时的数据读取效率，而不需要另外开发更为困难并且稳定性存疑的其它网络文件系统。在图3的系统中，云计算系统内所有服务节点和单一的存储阵列连接。如图9所示，在正常情况下，应用程序直接通过SAMBA协议访问存储阵列上的网络文件位置（虚线箭头）。而在微环境中，应用程序的访问实际被重定向到位于本地存储设备的缓存中。缓存内容由微环境进行管理。在计算节点首次运行应用程序时，微环境通过另一个基于rSync方案的协议（我们称为rSync_i）读取存储阵列上的网络文件。在读取时，多个并发的文件访问请求被按照目录位置合并为单一的TCP请求进行访问，使文件实际的读取速度得以接近网络环境所允许的极值。

多个计算节点将共同访问同一个存储节点上的应用程序数据，并将每个用户在执行应用程序时所产生的额外数据存储到单一的存储节点上。数据的导入导出和传输是通过微环境实现的。微环境使用了特定的策略来加速应用程序执行时从存储节点上读取数据的速率。系统将多个计算节点构成一个节点阵列，多个节点阵列共享一个存储节点（阵列）读取所执行的应用程序数据和记录用户生成的数据。用户可以通过网络延时和带宽等数据选择多个计算节点阵列中的一个。多个存储节点构成了可以相互同步的分布式存储系统。

用户客户端接受可识别的任意用户交互操作并通过控制信息发送到微环境中。然而，微环境的输入过滤模块将判别所有的用户操作并只允许特定的操作能发送到被执行的应用程序当中。这一判断是基于当前应用程序界面的状况而动态改变的。当当前光标在被判断为“危险”的界面（例如可以访问和执行计算节点本地存储路径的文件的窗口）时，输入过滤模块将能阻止远程用户执行可能对计算节点和整个服务系统有危险的操作。

从界面和声音导出模块输出的视/音频流和辅助信息流的数据被保存在如图4所示的微环境输出缓存模块中。因此，所执行的应用程序的界面等信息不仅可以被请求执行的用户的终端所看到，也可以通过输出缓存模块和传输模块输出到一个或多个以旁观者身份参与的用户的终端上。作为旁观者的用户连接同一个计算节点的微环境，但无法发送控制信息流到相应的微环境中。旁观者用户除了观看和程序交互的用户的行动之外，还可以通过其它通道发送特定的交互信息到云计算系统。如图10所示，一个特定的程序会在此微环境内启动，接收并汇总其它观看用户的交流信息。界面导出模块将这些交流信息和应用程序的界面合并为一个视频流，从而将这些交互信息被重新分发到当前所有连接此微环境的用户（包括交互用户和旁观者用户），并可以显示在所有用户的终端上。例如，在一个进行PC游戏的用户所在的微环境上，旁观者可以以文字形式实时地输入评论，这些评论将可以发送到所有的其它旁观者和游戏用户。

观看者的用户和执行交互的用户所访问的视频流是同步的（除了用户之间由于不同的网络延迟导致的影响）。然而，用户终端的视频解码模块一般并不能从一个有参考的帧（B帧）开始解码和正确显示视频流。在输出缓存模块中会保存已经向交互用户输出的一段时间内的全部视频帧数据，其中必然包含至少一个无参考的I帧。如图11所示，当一个观看者用户在最初连接微环境时，输出缓存模块将保存的离当前向交互用户的输出帧最近的I帧发送给观看者用户，直到有下一个I帧出现时，此帧将看观看者用户和交互用户同时输出。由于两个I帧出现的时间间隔可能长达10秒，这一策略显著减少了观看者用户的终端从连接成功到出现视频时的延迟。

一个被称为“展示墙”的特殊应用程序可以运行在一个独立的微环境中，如图12所示。展示墙访问计算系统内的服务管理器取得其它微环境内正在运行的应用程序，并作为观看者用户连接到这些微环境中。展示墙程序解码获取到的所有视频流，并将这些视频流以预览图的大小重新组织到一个单一的界面内。这一界面被编码为新的视频流发送到用户终端屏幕。用户可以选择展示墙内的某个预览视频流，并作为一个观看者用户与预览视频流对应的微环境内的其他用户进行交流。

微环境的视频和音频流在发送到网络前可以通过协议重整模块将两者合并为特定格式的多媒体内容流（如图4所示）。这样的多媒体内容流可以被进一步通过互联网抵达具有特殊实现的客户端终端程序。例如，从重整模块生成的多媒体内容流可以被以RTMP（Real Time Messaging Protocol）协议的方式承载并被广泛使用的Adobe Shockwave Flash平台所呈现。从而用户允许在不运行专门客户端程序的基础上使用云服务系统。例如，这使得任何用户只需要拥有一个可运行现代的Web浏览器的终端（所有的PC，上网本，WebOS系统以及大多数的移动终端等）即可作为一个观看者用户接入。

使用Adobe Shockwave Flash平台可以接收微环境发出的辅助信息流，并将用户在flash平台上的操作作为控制信息流发送到输入导入模块，从而实现一个完整的用户终端而不仅仅是观看者。然而，基于Flash平台的安全限制，执行远程应用程序时所需的某些交互行为不能被直接实现。例如部分键盘功能。一个典型的情况是，在某些应用程序例如第一人称视角的PC游戏中，允许鼠标向一个特定方向作无限的移动（对应于视角的不断转动）。但由Flash实现的客户终端只能在一个有限的矩形范围内接收的鼠标操作，当鼠标向一个方向移动导致指针移动到矩形的边缘时，后续的移动将无法再被检测到。

图13显示了对此问题的一个解决方案：接收鼠标指针移动信息的矩形区域被分割为两部分，在正常区域内，鼠标移动的信息被正常地发送到远程的应用程序。当鼠标指针移动到矩形边缘范围的缓冲边缘区域内时，在接受到下一次鼠标移动指令之前，最后一次移动的信息会以一定间隔被反复发送到远程应用程序，从而允许用户使用鼠标发送向特定方向持续移动的信息。在缓冲边缘区域时，特定的图案将显示在鼠标指针焦点位置附近，以提示用户一个特殊的移动行为正在发生。

在图3所示的服务系统中，服务管理器负责控制云系统中所有服务节点上全部微环境内执行的应用程序的状况，并将其和用户数据库关联起来。使用云计算远程交互程序服务的用户所执行的一个典型的工作流程如图14所示。用户的终端程序首先访问系统的前端（通常以Web的形式）获取通过安全网关和连接某一微环境的权限（1）；前端和服务管理器交互以在安全网关上为用户终端打开一个出口，并根据用户数据库的信息设置对应的微环境。当用户终端连接此微环境时，用户能在微环境上执行的应用程序的列表由服务管理器通过用户数据库信息所指定（2）；在用户执行特定的应用程序的过程中，相关的信息（例如执行的程序内容，执行时间，用户生成的数据等）被通过服务管理器传送回用户数据库（3）；最终，当用户执行应用程序完毕，用户离开微环境并告知服务管理器退出的信息．服务管理器将收集之前微环境中所需的信息同步到用户数据库，为用户下一次访问作准备（4）。

在远程交互程序服务应用中，网络环境对用户体验造成了最直接的制约。为了得到足够的用户体验，用户到计算节点的连结需要一个低延迟且高带宽的网络。通常，网络的传输延迟应该低于50毫秒。此外，测试表明在一个合理的分辨率水平（通常假设为1024x768）下，传输的视频流达到25-30FPS并保持足够的可读性要求最少2Mbps的带宽。这意味着一个云服务系统在同时服务大量用户时，网络的流量对系统网络出口将造成巨大的压力。

这样的云服务系统要求一个分布式的部署方案以便有效地利用差异化的网络带宽以提高传输效率和减少成本。如图15所示，分布式的计算服务节点阵列被部署于全国各地的多个位置，其服务用户终端的网络出口通常是流量费用较低的单线网络。多个部署的阵列通过专线和接入骨干网络上的分布式存储阵列相连接。所有这些分布式系统都以高质量但有限的带宽连接到中心数据库。用户的终端在访问web前端后，首先从连接多个计算服务节点并选择出连通性最佳的一个，再连接其中的某个节点的微环境以执行应用程序服务。在用户和应用程序交互过程中产生的用户数据文件将直接写入服务节点直接连接的存储阵列。在用户交互结束后，服务管理器将发出请求，在一个特定的时间域内（通常少于12小时），用户交互所产生的数据文件将被同步到全部的存储阵列中。而少量的核心数据则被实时地写入用户数据库。

这一分布式方案基于如下几点考虑：1. 单一的计算服务节点阵列所在的网络出口无法承受众多用户带来的带宽负荷并为所有用户提供满足要求的连接环境（最低2Mbps的带宽且延迟低于50ms）；2. 用户在执行一次交互程序时可能产生相当大量的用户数据。例如，当用户执行一个体育比赛类型的游戏时，可以对游戏中的某些场面进行录像并生成多达数百MB的数据文件。单一的存储阵列无法实时或准实时地和全部分布式的服务阵列完成海量的数据同步，但是，和有限的数组服务节点阵列作实时的数据同步是可能的；3. 由于地理条件的限制，用户在网络中可能的移动速度，将低于存储阵列之间完成同步的时间阈值。例如，假设有分布在北京和广州两个地区的存储阵列，用户存储到广州地区的存储阵列中的用户数据可以在最长12小时内和北京地区的阵列完成数据同步。而在绝大多数情况下，一个在广州地区结束服务的用户（我们假设其对应一个自然人的个体）在现有的交通运输水平内不会在12小时内在北京地区应用新的服务。这一现实的时间阈使上述的分布式方案成为可能。

Claims (1)

1.一种基于云计算的远程交互方法，其特征在于包括以下步骤：

在交互方的一端，接收鼠标指针移动信息的矩形区域被分割为两部分，包括正常区域与缓冲边缘区域；

在正常区域内，鼠标移动的信息被正常地发送到远程的应用程序；

当鼠标指针移动到矩形边缘范围的缓冲边缘区域内时，在接收到下一次鼠标移动指令之前，最后一次移动的信息以一定间隔被反复发送到交互方的另一端，使得用户使用鼠标发送向特定方向持续移动的信息；在缓冲边缘区域时，特定的图案将显示在鼠标指针焦点位置附近，以提示用户一个特殊的移动行为正在发生；

所述交互方的一端通过一安全网关将数据发送至所述交互方的另一端，所述安全网关包括一个或多个服务节点；所述服务节点进一步包括一处理单元，介于应用程序与系统API或者网络之间，包括一个函数地址监测模块，用于检测内存中应用程序的函数地址，以及一个函数地址重定向模块，用于改变应用程序的内存中存储的函数地址，对函数地址进行重定向；以及多个接口，用于与实现与计算机硬件以及API之间的通信；

所述交互方为计算机、或电视机顶盒、或移动终端设备；

所述服务节点将共同访问同一个存储节点上的数据，并将每个用户所产生的额外数据存储到单一的存储节点上；

所述多个服务节点构成一个节点阵列，多个节点阵列共享一个存储节点读取数据和记录用户生成的数据，用户通过网络延时和带宽等数据选择所述多个节点阵列中的一个。