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类的一些属性.

查看本文来源