一种桌面云场景下实时切换重定向方式的装置及方法与流程

本发明涉及通信技术领域，尤其涉及重定向方法及装置。

背景技术：

在桌面云的安全场景下，用户需要在虚拟机中使用智能卡用于认证，比如使用智能卡(Smart Card)用于虚拟机的登录。目前通用的技术是将客户端的智能卡重定向到虚拟机中使用，常用的重定向方式有设备接口层重定向和API(应用程序编程接口)重定向，设备接口层重定向主要包括总线重定向以及串口重定向、并口重定向等相应设备接口层的重定向。

设备接口层重定向和API重定向两种重定向方式各有优缺点，设备接口层重定向方式可以支持非PC/SC规范的智能卡重定向，API重定向方式可以满足在客户端和虚拟机同时使用智能卡的需求。用户需要根据不同的需求选择相应的重定向方式，有时也需要两种重定向方式相互切换使用。

在现有技术中，设备接口层重定向和API重定向由两个独立模块来实现。图1是现有技术中的设备接口层重定向方法示意图，其中，协议客户端101、协议服务端102、虚拟USB驱动模块103、虚拟USB驱动模块104是需要协议厂商实现的模块。

图1中，在使用设备接口层重定向时，对智能卡的消息处理方法如下：

步骤1～4，应用模块发起消息，该消息经传递到协议厂商实现的虚拟USB驱动模块；

步骤5，虚拟USB驱动模块将该消息转发给协议服务端的传输模块；

步骤6，该消息经过使用厂商定义的桌面云协议，再通过网络传输；

步骤7，该消息到达协议客户端后交给客户端的虚拟USB驱动模块；

步骤8～10，客户端的虚拟USB驱动模块将消息传递下去，最后由客户端的智能卡设备处理该消息并给出回应；

步骤11～20，智能卡设备处理后回应消息，最后该消息回到应用模块。

图2是现有技术中的API重定向方法示意，其中，协议客户端、协议服务端、智能卡资源管理器、app hook模块是需要协议厂商实现的模块。

图2中，在使用API重定向时，对智能卡的消息处理方法如下：

步骤21～22，应用模块发起消息，该消息传递到协议厂商实现的app hook模块(应用注入模块)；

步骤23，app hook模块将该消息转发给协议服务端的传输模块；

步骤24，该消息经过使用厂商定义的桌面云协议通过网络传输；

步骤25，该消息到达协议客户端后交给客户端的智能卡资源管理器；

步骤26～29，智能卡资源管理器将该消息传递下去，最后由客户端的智能卡设备处理该消息并给出回应；

步骤30～38，智能卡设备处理后回应消息，最后该消息回到应用模块。

上述两种重定向方式实质上都是在不同层次的消息栈上将消息进行截获并转发，不论采用哪种重定向方式，虚拟机的应用与智能卡资源管理器的SCard API(智能卡API)都是固定的。应用模块在使用智能卡时，通常有以下几种消息的调用：

1)应用模块调用SCardEstablishContext接口建立context(上下文)，后续接口的调用都使用到这个context；

2)应用模块调用SCardListCards接口和Scardlistreaders接口获取可用的读卡器信息；

3)应用模块调用SCardGetStatusChange接口查询智能卡状态，如果入参timeout参数为-1，此接口会阻塞直到卡的状态发生变化(比如由在位到不在位或者不在位变为在位)，这种情况下应用模块通常会启用两个及以上的线程，其中一个线程一直阻塞用于查询状态，其它线程做 相应的读写卡操作；

4)如果智能卡在位可操作，应用模块调用SCardConnect接口进行连接智能卡操作；

5)应用模块调用SCardTransmit接口进行传输数据；

6)数据传输完后，应用模块调用SCardDisconnect接口释放连接；

7)应用模块调用SCardFreeMemory接口释放内存；

8)应用模块调用SCardReleaseContext接口释放context结束操作；

在现有技术中，设备接口层重定向和API重定向是由两个独立的模块来实现的，从一种重定向方式切换到另一种重定向方式时，往往需要重启应用进程。然而对于系统进程比如Windows的winlogon进程、LogonUI进程等，重启应用进程会导致系统异常，甚至出现蓝屏。因此，在现有的技术方案中，如果要切换重定向方式，就需要重启操作系统，还需要用户修改虚拟机中的文件或者修改注册表项，并且还需要重启虚拟机才能够生效，影响使用效率和用户操作体验。

技术实现要素：

本发明提供了一种桌面云场景下实时切换重定向方式的装置及方法，以提高用户体验。

在第一方面，本发明提供了一种重定向方式切换方法且该重定向方式是将客户端中的设备重定向至虚拟机。该方法在设备接口层重定向方式下，应用模块调用与该设备状态变化相关的接口，并在该接口阻塞时，保存与该接口相应的上下文内容。然后基于虚拟机的断开，应用钩子模块根据该上下文内容释放该阻塞接口，并构造该设备不在位状态的消息通知。最后基于虚拟机的连接，应用钩子模块将设备重定向方式切换至API重定向。

在第二方面，本发明提供了一种重定向方式切换方法，且该重定向方式是将客户端中的设备重定向至虚拟机。该方法在API重定向方式下，应用模 块调用与该设备状态变化相关的接口，并在该接口需要阻塞时，应用钩子模块阻塞该接口。然后应用钩子模块轮询，以查询该设备状态变化情况，并在该设备状态发生变化时，释放该阻塞接口。基于虚拟机的断开，构造该设备不在位的消息通知。最后基于虚拟机的连接，应用钩子模块将设备重定向方式切换至设备接口层重定向。

在第三方面，本发明提供了一种重定向切换装置，且该重定向方式是将客户端中的设备重定向至虚拟机。该虚拟机包括应用钩子模块、应用模块。该应用模块在设备接口层重定向方式下用于调用与该设备状态变化相关的接口。该应用钩子模块用于在该与设备变化状态相关接口阻塞时，保存与该接口相应的上下文内容；以及在虚拟机断开情况下，根据该上下文内容释放该阻塞接口，构造该设备不在位状态的消息通知。并在连接该虚拟机后，将设备重定向方式切换至API重定向。

在第四方面，本发明提供了一种重定向切换装置，且该重定向方式是将客户端中的设备重定向至虚拟机。该虚拟机包括应用钩子模块、应用模块。该应用模块在API重定向方式下用于调用与该设备状态变化相关的接口。该应用钩子模块用于在该与设备变化状态相关接口需要阻塞时阻塞该接口。以及用于轮询，以查询该设备状态变化情况，并在该设备状态发生变化时，释放所述被阻塞接口。以及在虚拟机断开时构造该设备不在位的消息通知；并用于在连接该虚拟机后，将设备重定向方式切换至设备接口层重定向。

本发明提供的重定向方式切换装置及方法，解决了用户需要重新启动虚拟机才能够切换重定向方式的问题，减少了操作时间，降低了操作难度，解决了系统由切换重定向方式所带来系统异常的问题，提升了用户在桌面云场景下使用智能卡的体验，对智能卡的切换做到了即切即用。

较佳地，在应用模块调用与设备状态变化相关接口之前，应用钩子模块检测系统进程是否加载了与智能卡相关的模块，如果该应用钩子模块检测到已加载到该与智能卡相关的模块，则对系统进程进行注入。

较佳地，该设备状态变化相关的接口是智能卡获取状态变化接口。

较佳地，由智能卡取消接口释放阻塞接口。

较佳地，该设备接口层重定向是总线重定向、串口重定向、并口重定向中的一个。

较佳地，该设备是USB智能卡、串口智能卡、并口智能卡中的一个。

附图说明

图1为现有技术中的设备接口层重定向方法示意图；

图2为现有技术中的API重定向方法示意图；

图3为本发明一个实施例的从设备接口层重定向切换到API重定向的方法流程图；

图4为本发明一个实施例的重定向方式切换示意图；

图5为本发明一个实施例的从API重定向切换到设备接口层重定向的方法流程图；

图6为本发明一个实施例的从设备接口层重定向切换至API重定向的装置示意图；

图7为本发明实一个实施例的从API重定向切换至设备接口层重定向的装置示意图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

本发明中的重定向方式包括设备接口层重定向和API重定向，且该设备接口层重定向为总线重定向、串口重定向、并口重定向等设备接口层重定向中的一个。本发明中将客户端中的设备重定向至虚拟机，所述与客户端相关的设备可以是USB智能卡、串口智能卡、并口智能卡等智能卡中的一个，也可以是其它任意一种与客户端相关的设备，如打印机等，以下实施例将以该 与客户端相关设备为智能卡为例，对本发明进行详述。

本发明在智能卡状态变化相关接口(如SCardGetStatusChange接口)阻塞时，要切换重定向方式，就需要断开虚拟机，释放阻塞接口，并构造智能卡不在位状态的消息通知。否则与该智能卡状态变化接口相对应的资源就不会得到释放，因此此时一旦切换重定向方式，资源就无法得到正常调用，出现系统异常。除非采用现有技术中的重启虚拟机方式，这样又会给用户带来不便。

图3是本发明一个实施例的从设备接口层重定向切换到API重定向的方法流程图。

下述步骤301至步骤305阐述的是，如何通过设备接口层重定向方式将客户端的智能卡重定向至虚拟机。

S301，启动虚拟机。

S302，app hook模块(应用钩子模块)检测系统进程是否加载了与智能卡相关的模块，例如检测是否加载了windows系统的winscard模块。

S303，如果app hook模块检测到已加载到该与智能卡相关的模块，则对系统进程进行HOOK(注入)。

S304，此时，如果虚拟机的会话管理模块尚未提示连接虚拟机，则所有接口会返回一个值，如返回值SCARD_E_NO_SERVICE，该返回值表示系统的智能卡服务还未开始。

S305,如果虚拟机的会话管理模块提示连接该虚拟机，则用户连接上虚拟机，该app hook模块检测当前重定向方式，此时重定向方式为设备接口层重定向。

在该设备接口层重定向方式下，该智能卡中消息的处理过程参见图4。具体地，首先由应用模块发起消息，该消息传递到协议厂商实现的虚拟USB驱动模块。该虚拟USB驱动模块将该消息转发给协议服务端的传输模块。该消息经过使用厂商定义的桌面云协议，再通过网络传输。然后该消息到 达协议客户端后交给客户端的虚拟USB驱动模块。该客户端的虚拟USB驱动模块将消息传递下去，再由客户端的智能卡设备处理该消息并给出回应。最后经该智能卡设备处理后，回应消息至应用模块。

S306，所有设备API，如SCard API(智能卡API)，均经过该app hook模块，此时该app hook模块单独启用一个线程a，以监控阻塞的context(上下文内容)，且该context(上下文内容)能够示出智能卡、接口以及阻塞情况之间的对应关系。

下述步骤S307至步骤S312阐述的是，如何实时地将重定向方式切换至API重定向。

S307，该app hook模块判定用户是否登陆虚拟机。

S308,如果用户未登录虚拟机，所有接口返回一个值，如返回值SCARD_E_NO_SERVICE，表示智能卡服务还未开始。

S309，如果用户登录虚拟机，根据配置模块可知，此时已配置重定向方式为设备接口层重定向，则调用与该智能卡状态变化相关的接口，并在该接口阻塞时，保存与该接口相应的context(上下文内容)。

一个例子中，由应用模块(applications)进行接口调用，调用SCardGetStatusChange接口(智能卡获取状态变化接口)查询智能卡状态。如果入参timeout(超时)的参数值为-1等负数，说明该接口SCardGetStatusChange需要被阻塞。此时由驱动完成对该接口的阻塞，app hook模块仅需保存该接口相应的context(上下文内容)，该context(上下文内容)能够示出智能卡、接口以及被阻塞情况之间的对应关系。例如context示出了智能卡1中的SCardGetStatusChange接口阻塞、智能卡2中的SCardGetStatusChange接口不阻塞、智能卡3中的SCardGetStatusChange接口阻塞等；也就是说，该context示出了多个与智能卡状态变化相关接口的阻塞情况；因此，保存该context是为了根据该context中的信息，释放阻塞的接口。一个例子中，在智能卡数量为多 个情况下，如果需要切换重定向方式，则该多个智能卡重定向方式同时切换，且均由设备接口层重定向切换至API重定向，或者同时由API重定向切换至设备接口层重定向。S310，基于虚拟机的断开，app hook模块(应用钩子模块)释放该阻塞接口，并构造智能卡不在位状态的消息通知。

一个例子中，用户主动断开虚拟机或者由于网络异常导致客户端与虚拟机之间协议消息回应超时，此时线程a监控到虚拟机断开消息，则该app hook模块释放该阻塞的SCardGetStatusChange接口，并向应用模块(applications)构造智能卡拔出的消息通知，即智能卡不在位的消息通知。

进一步地，该app hook模块使用SCardCancel(智能卡取消)接口释放所有阻塞接口。

S311，应用模块(applications)调用SCard API(智能卡API)，所有接口返回一个数值，如返回值SCARD_E_NO_SERVICE，表示智能卡服务未开始。

S312，用户重连虚拟机。依据配置模块中的配置信息，app hook模块将智能卡的重定向方式切换至API重定向。

在此API重定向方式下，智能卡的消息处理过程参见图4。具体地，首先由应用模块发起消息，该消息传递到协议厂商实现的app hook模块。该app hook模块将该消息转发给协议服务端的传输模块，该消息经过使用厂商定义的桌面云协议通过网络传输。然后该消息到达协议客户端后交给客户端的智能卡资源管理器。该智能卡资源管理器将该消息传递下去，再由客户端的智能卡设备处理该消息并给出回应。最后经该智能卡设备处理后，回应消息至该应用模块。

图5为本发明一个实施例的从API重定向切换到设备接口层重定向的方法流程图。

下述步骤501至步骤505产生的是，如何通过API重定向方式将客户 端的智能卡重定向至虚拟机。

S501，启动虚拟机。

S502，app hook模块(应用钩子模块)检测系统进程是否加载了与智能卡相关的模块，例如检测是否加载了windows系统的winscard模块。

S503，如果app hook模块检测到已加载到该与智能卡相关的模块，则对系统进程进行HOOK(注入)。

S504，此时，如果虚拟机的会话管理模块尚未提示连接虚拟机，则app hook模块返回一个值，如返回值SCARD_E_NO_SERVICE，该返回值表示系统的智能卡服务还未开始。

S505,如果虚拟机的会话管理模块提示连接该虚拟机，则用户连接上该虚拟机，该app hook模块检测当前重定向方式，此时重定向方式为API重定向。

在该API重定向方式下，该智能卡消息处理过程参见图4。具体地，首先由应用模块发起消息，该消息传递到协议厂商实现的app hook模块。该app hook模块将该消息转发给协议服务端的传输模块，该消息经过使用厂商定义的桌面云协议通过网络传输。然后该消息到达协议客户端后交给客户端的智能卡资源管理器。该智能卡资源管理器将该消息传递下去，再由客户端的智能卡设备处理该消息并给出回应。最后经该智能卡设备处理后，回应消息至该应用模块。

S506,所有设备API,如SCard API(智能卡API),均经过该app hook模块,此时该app hook模块单独启用一个线程b，以监控阻塞的context(上下文内容)，且该context(上下文内容)能够示出智能卡、接口以及阻塞情况之间的对应关系。

下述步骤S507至步骤S513阐述的是，如何实时地将重定向方式切换至设备接口层重定向。

S507，该app hook模块判定用户是否登陆虚拟机。

S508,如果用户未登录虚拟机，所有接口返回一个值，如返回值SCARD_E_NO_SERVICE，表示智能卡服务尚未开始。

S509，如果用户登录虚拟机，根据配置模块可知，此时已配置重定向方式为API重定向，则调用与该智能卡状态变化相关的接口，并在该接口需要阻塞时，app hook模块阻塞该接口。

一个例子中，由应用模块(applications)进行接口调用，调用SCardGetStatusChange接口(智能卡获取状态变化接口)查询智能卡状态。如果入参timeout的参数值为-1，说明该接口SCardGetStatusChange需要阻塞，则由app hook模块阻塞该接口。需要说明的是，该SCardGetStatusChange接口什么时候需要被阻塞由运行该智能卡的系统决定，只要该系统发送至该SCardGetStatusChange接口的入参timetout为负数，则该SCardGetStatusChange接口需要被阻塞，直到智能卡状态发生变化。

S510，app hook模块定时轮询，以查询智能卡状态变化情况，如果智能卡状态发生变化，则释放该阻塞的接口。

一个例子中，app hook模块定时轮询，去客户端查询智能卡状态是否发生变化，如果智能卡由在位状态变为不在位状态或者由不在位状态变为在位状态，则释放阻塞的SCardGetStatusChange接口。

S511，基于虚拟机的断开(用户主动断开虚拟机或者由于网络异常导致客户端与虚拟机之间协议消息回应超时)，应用模块调用智能卡API(SCard API),构造智能卡不在位的消息通知，即向应用模块发送智能卡不在位的消息通知。所有接口(包括SCardGetStatusChange接口)返回一个值，如返回值SCARD_E_NO_SERVICE，表示智能卡服务未开始。

S512，用户重连虚拟机。依据配置模块中的配置信息，app hook模块将智能卡的重定向方式切换至设备接口层重定向。

在此设备接口层重定向方式下，智能卡中消息的处理过程参见图4。 具体地，首先由应用模块发起消息，该消息传递到协议厂商实现的虚拟USB驱动模块。该虚拟USB驱动模块将该消息转发给协议服务端的传输模块。该消息经过使用厂商定义的桌面云协议，再通过网络传输。然后该消息到达协议客户端后交给客户端的虚拟USB驱动模块。该客户端的虚拟USB驱动模块将消息传递下去，再由客户端的智能卡设备处理该消息并给出回应。最后经该智能卡设备处理后，回应消息至应用模块。

图6是本发明一个实施例的从设备接口层重定向切换至API重定向的装置示意图。

客户端通过网络将该客户端中的智能卡重定向至虚拟机，该智能卡被插入至客户端，该虚拟机包括app hook模块601(应用钩子模块601)、配置模块602、会话管理模块603、应用模块604。

该应用模块604在该虚拟机被登录情况下，用于调用与该智能卡状态变化相关的接口。

该app hook模块601用于在该与智能卡变化状态相关接口需要被阻塞时，保存与该接口相应的上下文内容(context)；该app hook模块601还用于虚拟机断开情况下，释放该被阻塞接口，并构造该智能卡不在位状态的消息通知；并在该虚拟机被连接后，用于将该智能卡重定向方式切换至API重定向。

该会话管理模块603用于提示用户已连接虚拟机。

该配置模块602用于提供配置信息，包括由设备接口层重定向切换至API重定向的配置信息、由API重定向切换至设备接口层重定向的配置信息、设备接口层重定向的配置信息、API重定向的配置信息等等。

进一步地，该app hook模块601在虚拟机被启动后，还用于检测系统进程是否加载了与智能卡相关的模块(例如检测是否加载了windows系统的winscard模块)，若加载了该模块，则对系统进程进行HOOK(注入)。

进一步地，该app hook模块601还用于启动线程，以监控阻塞的context(上下文内容)。

进一步地，该app hook模块601还用于判定用户是否已经登陆虚拟机。

进一步地，该app hook模块601还用于释放被阻塞的接口，并构造智能卡不在位状态的消息通知。

进一步地，该应用模块604用于调用SCardGetStatusChange接口(智能卡获取状态变化接口)，以查询智能卡状态。

图7是本发明一个实施例的的从API重定向切换至设备接口层重定向的装置示意图。

客户端通过网络将该客户端中的智能卡重定向至虚拟机，该智能卡被插入至客户端，该虚拟机包括app hook模块701(应用钩子模块701)、配置模块702、会话管理模块703、应用模块704。

该应用模块704在该虚拟机被登录情况下，用于调用与该智能卡状态变化相关的接口。

该app hook模块701用于在该与智能卡状态变化相关接口需要被阻塞时，阻塞该接口；以及用于定时轮询，以查询该智能卡状态变化情况，并在其状态发生变化时，释放该被阻塞接口；以及在虚拟机断开时构造智能卡不在位的消息通知；并在该虚拟机被连接后，将该智能卡重定向方式切换至设备接口层重定向。

该会话管理模块703用于提示用户已连接虚拟机。

该配置模块702用于提供配置信息，包括由设备接口层重定向切换至API重定向、由API重定向切换至设备接口层重定向、仅设备接口层重定向、仅API重定向等等。

进一步地，该app hook模块701还用于在虚拟机被启动后，检测系统进程是否加载了与智能卡相关的模块(例如检测是否加载了windows系统的winscard模块)，若加载了该模块，则对系统进程进行HOOK(注入)。

进一步地，该app hook模块701还用于启动线程，以监控阻塞的context(上下文内容)。

进一步地，该app hook模块701还用于判定用户是否已经登陆虚拟机。

进一步地，该应用模块704在虚拟机被断开后，还用于调用智能卡API(SCard API)。

进一步地，该应用模块704还用于调用SCardGetStatusChange接口(智能卡获取状态变化接口)，以查询智能卡状态。

综上，本发明切换重定向方式，仅需要用户断开虚拟机后再连接虚拟机，就能够实现，不需要用户重新启动虚拟机。在现有技术中，如果要切换重定向方式，就需要热启动虚拟机还要用户修改虚拟机中的与新的定向方式相对应的文件或者需要用户修改注册表项。并且重连虚拟机相对于热启动虚拟机来说，操作时间更短，用户体验更佳。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而 已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。