ASP.NET Remoting体系结构（二）:信道

信道

信道是跨远程处理边界，在应用程序之间传输消息的对象。信道可以在终结点上侦听入站消息，向另一个终结点发送出站消息，或者两者都可以。这使用户能够插入各种各样的协议，即使信道的另一端上没有公共语言运行库。

信道分为HTTP信道和TCP信道。下面进行详细介绍信道的相关知识。

1．HTTP信道

HTTP信道使用SOAP协议与远程对象传输消息。所有的消息流过SOAP格式化程序时都被转换为 XML 格式且被序列化，所须的 SOAP 头也会被添加到该流中，也可以指定能够生成二进制数据流的二进制格式化程序。然后，数据流会使用 HTTP 协议传输到目标URI。

2．TCP信道

TCP 信道使用二进制格式化程序将所有的消息序列化为二进制流，并使用 TCP 协议将其传输到目标URI。

在Remoting体系结构中，信道用于在远程对象之间传输消息。当客户端调用某个远程对象的方法时，与该调用相关的参数以及其他详细信息会通过信道传输到远程对象。调用的任何结果都会以同样的方式返回给客户端。客户端可以选择“服务器”中注册的任一信道，以实现与远程对象之间的通信，因此开发人员可以自由选择最适合的信道。当然，用户也可以自定义任何现有的信道或创建使用其他通信协议的新信道。信道选择遵循以下规则。

在能够调用远程对象之前，远程处理框架必须至少注册一个信道。信道注册必须在对象注册之前进行。

信道按应用程序域注册。一个进程中可以有多个应用程序域。当进程结束时，该进程注册的所有信道将被自动清除。

多次注册侦听同一端口的信道是非法的。即使信道按应用程序域注册，同一计算机上的不同应用程序域也不能注册侦听同一端口的信道。

在Remoting体系结构中，客户端可以使用任何已注册的信道与远程对象通信。当客户端试图连接至某个远程对象时，远程处理框架会确保该对象连接至正确的信道。客户端负责在尝试与远程对象通信之前调用ChannelService类的RegisterChannel方法。

在Remoting体系结构中，所有的信道都继承了 IChannel 接口，并根据信道的用途实现 IchannelReceiver接口或 IchannelSender接口。大多数信道既实现了接收器接口，又实现了发送器接口，使它们可以在两个方向上通信。当客户端调用代理上的某个方法时，远程处理框架会截取该调用并将其转为要发送到 RealProxy 类（或一个实现 RealProxy 类的实例）的消息。RealProxy类将消息转发到消息接收器以进行处理。消息接收器负责与远程对象注册的信道之间建立连接，并通过信道（在不同的应用程序域）将消息从调度位置传输到远程对象本身。激活了一个远程对象后，客户端会通过调用选定信道上的CreateMessageSink（消息接收器）来选择信道，并从其上检索能够与远程对象通信的消息接收器。

在远程处理框架中，使用信道容易混淆的方面是远程对象和信道之间的关系。例如，如果 SingleCall远程对象只在被调用时才激活，那么该对象如何侦听要连接的客户端。

远程对象并不拥有自己的信道，而是共享信道。作为远程对象宿主的服务器应用程序必须注册要通过远程处理框架公开的对象以及所需的信道。注册后的信道会自动开始在指定的端口侦听客户请求。注册远程对象后，会为该对象创建一个 ObjRef (对象引用)并将其存储在表中。当信道上传来一个请求时，远程处理框架会检查该消息以确定目标对象，同时检查对象引用表以定位表中的引用。如果找到了对象引用，将从表中检索框架目标对象或在必要时将其激活，然后框架将调用转发至该对象。对于同步调用，在消息调用期间会一直维持来自客户端的连接。因为每个客户端连接都在自己的线程上处理，所以一个信道可以同时服务于多个客户端。