一种跨域访问服务的方法及系统
技术领域
本发明涉及计算机技术领域,具体地,涉及一种跨域访问服务的方法及系统。
背景技术
虚拟化技术是一种将底层硬件设备与上层操作系统、应用程序进行分离去耦合的技术。虚拟化技术作为当前流行的云计算平台的底层重要支撑技术之一,可极大的提高物理设备的资源使用效率。特别是随着智能通信设备日益多样化以及通信设备性能的不断提升,目前通信设备(例如智能手机)的硬件资源处于相对过剩状态。使用虚拟化技术虚拟多个操作系统,可以实现不同安全等级的应用相互隔离,改善系统的安全性能。
容器是一种轻量级的虚拟化技术。容器技术可以按需构建容器数量,这无疑能够大大提升工作效率。Linux容器(Linux Container)为当前研究最热的容器技术之一,由于Android系统是一个以Linux内核为基础的开源移动设备操作系统,这使Linux容器可以很方便地部署在Android系统上。鉴于Android系统的开源性,向Android系统进入虚拟化技术能够很好地改善Android系统的安全性。目前,哥伦比亚大学的Cells以及浙江大学的Condroid均是基于Linux容器的Android虚拟化产品。
采用容器虚拟化技术创建多个容器的同时,对多个容器进行管理的host角色是必不可少的。所有的容器(子命名空间,简称“子域”)隶属于一个外部的环境(根命名空间,简称“根域”),后者为支持容器的创建、销毁、切换以及资源互斥、设备复用等事件进行统一的管理。管理的手段多种多样,针对不同的功能模块可以有不同的解决方案,其中就可能涉及到需要使用特定容器内部服务的方案,但是在不修改目标服务程序代码的前提下不可能跨越命名空间(跨域)直接与其建立通信。本发明即提供一种方法以解决从根域访问子域系统服务的技术问题,涉及到Binder通信机制。
Binder通信机制:
在Android中,系统服务基本都采用Binder来完成进程间通信(IPC)。Binder意即把多个进程关联在一起,比如,普通应用程序可以调用音乐播放服务提供的播放、暂停、停止等功能。Binder工作在Linux层面,属于一个驱动,只是这个驱动不需要硬件,或者说其操作的硬件是基于一小段内存。从线程的角度来讲,Binder驱动代码运行在内核态,客户端程序调用Binder是通过系统调用完成的。Binder通信机制有三个角色:服务端(Server),客户端(Client)和Binder守护进程(ServiceManager)。ServiceManager负责接收Server的注册请求并将Server的Binder对象实体存储在Binder驱动,之后Client可以向ServiceManager请求Server的Binder引用,从而建立起Client和Server之间的Binder通信,Client即可向Server请求功能服务。
现有技术中的多容器架构Condoird对Binder驱动做了虚拟化,甄别出各容器共有的服务端,如SurfaceFlinger,加以管理并复用,在多容器存在的场合下可以有效地降低内存的消耗。然而,在容器数量较少的情况下,由于具有一定的管理开销,整体的性能难有明显的提升,而目前市场上实际使用时也仅仅运行两个系统(双系统手机),因此是否把服务放到根域的性能区别并不大。另一方面,针对每个共有服务,Condroid都要进行分析和实现一套管理机制,增加了系统复杂度和开发复杂度。最后,各容器共享部分系统服务,提高了聚合度降低了独立性,势必带来一定的安全性损失。相反,各容器独立保留自身运行所必须的全部系统服务,则没有以上问题。而根域客户端程序在需要时如何跨越命名空间隔离与子域服务端建立联系,则是本发明所要解决的主要技术问题。
发明内容
本发明提供了一种跨域访问服务的方法及系统,克服了进程命名空间对异域程序的隔离障碍,实现了根域程序对子域服务的访问。
为解决上述技术问题,本申请实施例提供了一种跨域访问服务的方法,所述方法包括:
步骤1:通过根域客户端发起子域服务查询请求;
步骤2:根域服务管理模块向子域服务管理模块发起通信,获得子域服务端通信机制引用信息;
步骤3:根域客户端基于获得的子域服务端通信机制引用信息,与子域服务端建立通信连接。
其中,在本申请中,用户首先通过根域客户端发起子域服务查询请求;然后根域服务管理模块向子域服务管理模块发起通信,获得子域通信机制引用信息;最后,根域客户端基于获得的子域服务端通信机制引用信息,与子域服务端建立通信连接。即通过通信机制引用信息与子域服务端建立通信连接,克服了进程命名空间对异域程序的隔离障碍,实现了根域程序对子域服务的访问。
进一步的,所述获得子域服务端通信机制引用信息,具体为:利用服务管理模块与客户端程序通信,获取客户端请求通信的目标服务端与容器的对应关系,使用系统调用向通信机制驱动获取子域服务管理模块的通信机制引用信息。
进一步的,所述获取客户端请求通信的目标服务端与容器的对应关系,具体包括:
首先,根域服务管理模块向客户端发起通信,获取目标子域的容器名称;
然后,根域服务管理模块根据容器名称查询根域目录下的容器配置文件,获得子域的初始进程信息。
进一步的,所述使用系统调用向通信机制驱动获取子域服务管理模块的通信机制引用信息,具体包括:
首先,根域服务管理模块通过系统调用将目标子域的初始进程信息发送给通信机制驱动;
然后,通信机制驱动根据子域的初始进程信息查询指定的通信机制设备命名空间,获得子域服务管理模块的通信机制引用,并返回给根域服务管理模块。
进一步的,所述步骤2具体包括:
步骤2.1:根域服务管理模块向客户端发起通信,获取目标子域的容器名称;
步骤2.2:根域服务管理模块根据容器名称查询根域目录下的容器配置文件,获得子域的初始进程信息;
步骤2.3:根域服务管理模块通过系统调用将目标子域的初始进程信息发送给通信机制驱动;
步骤2.4:通信机制驱动根据子域的初始进程信息查询指定的通信机制设备命名空间,获得子域服务管理模块的通信机制引用,并返回给根域服务管理模块;
步骤2.5:根域服务管理模块通过通信机制与子域服务管理模块建立联系,将客户端程序的服务查询请求转发给子域服务管理模块;
步骤2.6:子域服务管理模块根据请求消息查询子域内的服务,将目标服务端的通信机制引用返回给根域服务管理模块;
步骤2.7:根域服务管理模块将目标子域服务端的通信机制引用返回给发起服务查询请求的根域客户端。
其中,步骤2.1、2.2讲述的是服务管理模块(后面简称SM,即ServiceManager)获得客户端请求的意向容器的手段,从而得知客户端请求通信的目标服务端与容器的对应关系。由于单纯的系统调用并不会告知SM额外的信息,SM只会知道客户端需要哪个服务,但不知道这个服务的具体位置信息,因此需要其他手段来获悉该信息,而本申请中的方法能够获得客户端请求通信的目标服务端与容器的对应关系,通过对应关系进而能够明确目标服务所处容器的位置信息。
进一步的,本方法用于基于Linux容器的多Android系统虚拟化平台中。其中,该平台具有两个特点,一是命名空间隔离,Linux容器技术的应用,将多个系统分别隔离在其所属的命名空间中,独立运行,互不干扰,数据资源也互不共享;二是Android系统所具有的一种进程和服务间通信的特色方式——Binder通信机制,该机制基于内核的Binder驱动,通过ServiceManager管理服务进程对象的引用,允许经过验证的客户端进程申请取得某服务的引用,从而享受该服务提供的功能,本方法即主要针对同时具有这两个特点的平台。
另一方面,本申请还提供了一种跨域访问服务的系统,所述系统用于基于Linux容器的Android虚拟化平台中,所述系统包括:
请求单元,所述请求 单元用于通过根域客户端发起子域服务查询请求;
查询单元,所述查询单元用于根域服务管理模块向子域服务管理模块发起通信,获得子域服务端通信机制引用信息;
通信单元,所述通信单元用于根域客户端基于获得的子域服务端通信机制引用信息,与子域服务端建立通信连接。
其中,所述查询单元具体包括:
第一获取模块,所述第一获取模块用于利用服务管理模块与客户端程序通信,获取客户端请求通信的目标服务端与容器的对应关系。
第二获取模块,所述第二获取模块用于使用系统调用向通信机制驱动获取子域服务管理模块的通信机制引用信息。
其中,所述第一获取模块具体包括:
第一获取子模块,所述第一获取子模块用于根域服务管理模块向客户端发起通信,获取目标子域的容器名称;
第二获取子模块,所述第二获取子模块用于根域服务管理模块根据容器名称查询根域目录下的容器配置文件,获得子域的初始进程信息。
其中,所述第二获取模块具体包括:
发送子模块,所述发送子模块用于根域服务管理模块通过系统调用将目标子域的初始进程信息发送给通信机制驱动;
第三获得子模块,所述第三获得子模块用于通信机制驱动根据子域的初始进程信息查询指定的通信机制设备命名空间,获得子域服务管理模块的通信机制引用,并返回给根域服务管理模块。
本申请实施例中提供的一个或多个技术方案,至少具有如下技术效果或优点:
1. 支持根域程序对子域服务的跨域访问。
2. 不仅可应用于开源程序,也适用于闭源程序,本发明描述的方法主要是对服务的查询过程做修改,对binder通信双方是不可见的,因此不用改动双方的接口。
3. 实现简单,在为Binder驱动添加设备命名空间支持的基础上,只需实现ServiceManager通过与客户端程序通信建立“客户端-容器”映射表、使用系统调用向Binder驱动获取子域ServiceManager的Binder引用等操作。
附图说明
此处所说明的附图用来提供对本发明实施例的进一步理解,构成本申请的一部分,并不构成对本发明实施例的限定;
图1是本申请实施例一中跨域访问服务架构示意图;
图2是本申请实施例一中跨域访问服务流程示意图;
图3是本申请实施例一中跨域访问服务Radio实例示意图。
具体实施方式
本发明提供了一种跨域访问服务的方法及系统,克服了进程命名空间对异域程序的隔离障碍,实现了根域程序对子域服务的访问。
为了更好的理解上述技术方案,下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。
下面结合具体实施例及附图,对本发明作进一步地的详细说明,但本发明的实施方式不限于此。
实施例一:
本申请提供了一种跨域访问服务的方法,适用于基于Linux容器技术(LinuxContainer)的Android虚拟化平台,克服了进程命名空间对异域程序的隔离障碍,主要应用于根域程序对子域服务的访问。所述的跨域访问服务方案包括以下三个步骤,下面将结合附图1-2进行说明。
1. 根域客户端通过Binder向根域ServiceManager发起子域服务查询请求。
2. 根域ServiceManager向子域ServiceManager发起子域服务查询请求:
2.1 根域ServiceManager向客户端发起通信,获取目标子域的容器名称(container_name);
2.2 根域ServiceManager根据容器名称查询根域目录下的容器配置文件,取得子域的初始进程id(init_pid);
2.3 根域ServiceManager通过系统调用(ioctl)将目标子域的init_pid发送给Binder驱动;
2.4 Binder驱动根据子域init_pid查询指定的Binder设备命名空间(binder_ns),获得子域ServiceManager的Binder引用,并返回给根域ServiceManager;
2.5 根域ServiceManager通过Binder与子域ServiceManager建立联系,将客户端程序的服务查询请求转发给子域ServiceManager;
2.6 子域ServiceManager根据请求消息查询子域内的服务,将目标服务端的Binder引用返回给根域ServiceManager;
2.7 根域ServiceManager将目标子域服务端的Binder引用返回给发起服务查询请求的根域客户端。
3. 根域客户端得到子域服务端的Binder引用,与子域服务端建立Binder通信。
下面结合附图3,以Radio设备代理为例,描述本发明所述的跨域提取服务实施过程。
本例主要包含Binder通信过程中的4个组件:客户端(Radio代理和厂商动态库),服务端(audioflinger),ServiceManager和Binder驱动。在基于Linux容器的Android虚拟化平台上,本发明的实施步骤如下:
1. 位于根域的厂商闭源库通过binder向同在根域的ServiceManager发起子域服务audioflinger的查询请求。
2. 根域ServiceManager根据厂商闭源库的pid查询客户端与容器的映射表,从而得到目标容器的信息(init_pid和容器名),否则对映射表进行初始化:
1) ServiceManager对客户端程序(Radio代理,RIL_Host)发起通信,获取其存储的目标容器的名称;
2) ServiceManager根据容器名字,查询根域系统目录下的容器信息配置文件,即可获得容器的init_pid。
3. 根域ServiceManager通过系统调用(ioctl)将目标容器的init_pid传给Binder驱动,发起查询子域ServiceManager的请求。
4. Binder驱动根据init_pid找到对应的Binder设备命名空间,即binder_ns对象,从而得到该设备命名空间中的ServiceManager服务节点(context_mgr_node),经过处理可得到目标子域ServiceManager的Binder引用。
5. 根域的ServiceManager取得目标子域ServiceManager的Binder引用后,将1.中厂商闭源库对子域服务的查询请求通过Binder转发给目标子域ServiceManager,发起子域服务查询请求。
6. 子域ServiceManager根据请求消息查找本域的audioflinger服务,得到该服务的Binder引用,随后返回给根域ServiceManager;根域ServiceManager将该Binder返回给1.中发起请求的厂商闭源库。
7. 发起请求的客户端程序(厂商闭源库)拿到目标子域服务(audioflinger)的引用后,即可通过binder与目标子域服务进行通信,从而实现相关功能。
上述本申请实施例中的技术方案,至少具有如下的技术效果或优点:
1. 支持根域程序对子域服务的跨域访问。
2. 不仅可应用于开源程序,也适用于闭源程,本发明描述的方法主要是对服务的查询过程做修改,对binder通信双方是不可见的,因此不用改动双方的接口。
3. 实现简单,在为Binder驱动添加设备命名空间支持的基础上,只需实现ServiceManager通过与客户端程序通信建立“客户端-容器”映射表、使用系统调用向Binder驱动获取子域ServiceManager的Binder引用等操作。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。