[转载]如何使用IPC通道和.NET框架2.0实现进程间通信
内部进程间通信(IPC)指运行在同一台计算机中的不同进程之间进行通信。由于IPC的调用无需通过网络,相对于网络通信来说它更可靠也更高速。有很多种不同类型的IPC调用,但是在windows系统中大部分IPC调用都通过命名管道来实现。
在.NET中,FCL(框架类库)并不直接支持命名管道。假如开发人员需要在现存系统中使用命名管道来通信,可以进入到COM层再写一个包装类来访问命名管道。但是如果与别的进程进行通信的进程是在.NET 框架2.0的基础上创建的话,我们可以采用IPC通道来进行通信。
IPC通道是建立在Windows IPC 系统上层的远程通道。假如你熟悉编写远程通信应用程序的话,新的IPC通道对于你来说就很容易了。IPC通道和其他远程通道(如:HTTP和TCP通道)都非常相似,只是在有些功能函数上有差异。最显著的差异在于IPC通道只有当通信双方的进程都在同一机器内才起作用,这确实存在局限性但优势是更可靠和有更高速的性能。
如何使用新的IPC通道
要使用新的IPC通道,你先得看看你的体系结构是否能保证通信成功。这个结构至少应该有以下层次/配件:
◆共享对象?指IPC服务端和IPC客户端都能访问到的对象。这个对象应该是一个独立的工程或者配件,并且不应该只有客户端或服务端一方才能引用。在例子中,这一层由SharedObject工程来实现。
◆IPC客户端?这一层/配件用来调用服务端提供的服务和功能。IPC客户端需要能访问到共享对象。在例子中,这一层由Client工程来实现。
◆IPC服务端?这一层/配件用来建立IPC服务通道,并提供客户端程序可以使用的功能。在例子中,这一层由Server工程来实现。
同样,你应该确保你的客户端和服务端工程都能引用System.Runtime.Remoting, 包括里面的channels类,用以下代码实现这些引用:
|
共享对象层
在例子中,SharedObjects工程包含二个对象:ServerData和ServerMethods。其中ServerData用于存储目前Server的信息,它不需要在客户端和服务端来回列集(marshaled)和反列集(unmarshaled)处理。ServerMethods这个对象我们应该着重关注,因为它是一个被列集处理(marshaled)过的对象。ServerMethods对象的代码如下列表A。
列表A:
|
我们可以注意到这个类是由MarshalByRefObject类继承来的,从而ServerMethods类能突破应用程序的界线。如果不继承这个类的话,ServerMethods对象就不能跨域,那它就只能简单的在被调用的域内实例化了。点击这里可看到更多的有关MarshalByRefObject的信息。
服务端层
在例子中,服务端层是由Server工程来实现。里面有一个windows窗体,它用来创建要加载的通道。内部的From1_Load事件的代码如下列表B。
列表B:
|
这段代码实例化一个IpcServerChannel类并命名为“ServerChannel”,再用ChannelService类来注册通道和注册服务,接着设置ServerData类的一些属性。
RegisterWellKnownServiceType调用非常重要,因为它告诉远端库它所能提供的对象和这些对象的URI。在上面代码的调用中,我们提供了一个ServerMethods对象。这个对象完整的URI近似于下面的地址,实际上这也是客户端用来连接服务端的URI:
ipc://ServerChannel/ServerMethods
URI的格式是:ipc://[channel_name]/[method_name]. “ServerChannel”的通道名用以下代码来定义:
|
客户端层
在例子中,客户端层是由Client工程来实现的,近似于Server工程,你能在客户端工程中找到一个独立的windows窗体,创建客户端通道并为IPC注册了一些类型。内部的Form1_Load事件的代码如下列表C。
列表C:
|
这段客户端的代码非常类似于服务端,除了客户端实例化IpcClientChannel而服务端实例化IpcServerChannel以外,还有就是用客户端用RegisterWellKnownClientType替代服务端里的RegisterWellKnownServiceType。
RegisterWellKnownClientType的作用就是告诉远端基础设施客户端想要远程访问的类型(类)和通过什么URI来访问。
在我们这里的客户端例子中,我们通过URI ipc://ServerChannel/ServerMethods来远程访问ServerMethods类。请注意这里的URI和你在Server工程中建立的URI是一样的。
一旦通道和类型建立后,你就可以实例化这些类,其方式和你实例化其他C#类是完全一样的。
server = newServerMethods();
当以上声明执行后,远端基础设施会连接上服务端,创建一个新的对象并通过远程调用这个对象作为服务端到客户端的代理。btnCallServer_Click方法示范了这个过程,代码如下列表D。
列表D:
|
每一个对“server”(实际上是代理)对象的调用都传到了IPC服务端,服务端再通过“Server”对象将数据返回给客户端。服务端可以在它的程序域中修改数据,并允许客户端从客户端的程序域中查看它的数据。
ServerMethods.IsProcessing属性就是一个好的例子。这个属性的值每2秒就在IPC服务端更新一次,从“Yes”到“No”,或者反过来。因为这个值客户端是可以访问到的,所以即使它不能改变这个值但也能看到值的变化。
运行例子
运行例子,先在Visual Studio 2005中打开InterprocessCommunication solution文件,然后点右键重建方案,方案重建后,打开Client和Server的创建目录。你先得双击“Server.exe”来执行服务端,然后双击“Client.exe”执行客户端。
客户端启动后,点“Call Server”按钮,你能在按钮下得文本框里看到以下的结果:
|
等大约一秒再点击“Call Server”按钮,点击后一会儿你就会看见“Is Processing”状态变为“No”。你也可以点击服务端程序的“Set Status to Bad”按钮,然后再点击客户端的“Call Server”按钮,你就可以看见“Status”变为“Bad”。
结束语
如你所见,IPC通道非常适用于从一个应用程序中监控另外一个应用程序的情况。特别是可用于那种没有提供用户接口但又要提供windows服务的服务端程序。
阅读全文类别:信息技术 查看评论