Secure Your .NET Remoting Traffic by Writing an Asymmetric Encryption Channel Sink ()

看了一下这篇文章，只对一些信息进行了翻译。希望大家一起学习.

引用网址：http://msdn.microsoft.com/msdnmag/issues/03/06/NETRemoting/void

Remoting Execution and Extensibility(Remoting执行和扩展)

When a client requests a reference to a remote object, it is returned a reference to a TransparentProxy—an object that appears to have the same methods and properties as the remote object and that appears to behave in a similar fashion, but which begins the process of delegation when a call is placed.

当一个客户端请求引用一个远程对象，它返回该引用的透明代理—一个看来与远程对象具有相同方法与属性的对象，它的行为也看起来非常相似，但它是通过调用代理进行调用的。

TransparentProxy创建一个调用，并将一MessageData对象传入其他其他代理，这个对象继承自RealProxy(经常，但并非一定，RemotingProxy). 该代理依次从MessageData中创建一个Imessage并转发包含信息的消息到一系列message sink的调用方法上。(这些类实现ImessageSink或IDynamicMessageSink),这些message sink能修改或取代这个消息再发送出去。

在链的最后一个ImessageSink 必须为formatter sink, 它经常实现IclientFormaterSink接口,是IclientChannelSink与ImessageSink两个接口的结合物。该Sink主要负责为送入的IMessage创建transportheader并将它序列化为stream. 这个Stream,一系列的header,以及Imessage,只在引用中使用，然后经过一系统的IclientChannelSinks,每个的Sink都可以替换新stream到数据中，并将它提供给下一个sink(). 在这些sink的最后，是传输sink,将头信息和stream通过如Http连接或命名管道进行传输，将数据发送给服务器。

一个类似的过程同样发生在服务器端，但是整个过程恰恰相反。服务器端的传输sink从客户端的传输sink接收到头信息和stream。数据经过一系列的IserverChannelSink 对象的处理(包括SdlChannelSink,用于生WSDL)，就像客户端那样。格式器，一个IserverChannelSink,将一系列头信息和stream反序列化进一个原始Imessage的克隆对象，然后转发给一系列的IserverChannelSink, Imessage以及IdynamicMessageSink对象，直到到达最终的Sink—StackBuilderSink. 该sink使用反射执行请求并获取返回值。 返回消息通过相同的sink,穿过传输层，返回到客户端的sink一直到代理上，返回值并输出参数。

你可以看到，当使用remoting对象时，有一系列的场景有后台发生。这样的好处之一，如图2，有很多的空间可以插入自定义功能。格式器能序列化和反序列化成一种特定的格式(内置的SOAP和Binary格式器，你可以根据需要任选其一). 另外，ImessageSinks可能修改现有的消息再发送。IclientChannelSinks和IserverChannelSinks能够修改stream和一系列头信息。自定义的真实代理可以回溯和修改实际执行信息。 并且，传输sink可以使用开发者认为合适的任何传输层发送和接收数据。

对于加密Sink,你必须在客户端与服务器端进行传输前进行对数据进行修改。你不需要特定的传输层或格式器，也不需要在序列化前修改消息。最好的插入空间(最通用的拦截点，也已经看到使用过)在格式器与传输sink之间。可以熟练的实现自定义。