这两天由于公司业务的需要，需要将一项服务放到互联网上，采用的框架为.net remoting。.net remoting在使用上很简单，功能也很强大，是开发分布式应用程序的首选。但是.net remoting框架在传输数据时，并没有对数据进行加密处理和身份认真，所以这让我有了数据安全性的担心。

但是.net 框架确实很强大，强大到可以让你自定义数据传送的方式，所以将安全策略加入到自定义的传送中是一个不错的选择。

但是这个自定义传送方式让我研究了2天时间，我将所有的接口定义都打印出来，将在网上找到的一篇关于custom channel sinks的资料也打印了出来，一句一句分析，最后在今天下班的路上，我突然觉得我完全理解了custom channel sink的工作流程，知道了如何将安全策略加入到custom channel sink中。

在以后几天中，我会把原理写在我的blog上，希望路过的朋友多多指教。

原理

 当你调用远程对象时，你并没有直接引用它，你引用的是远程对象在本地的代理。代理对象在处理上很像远程对象，它能够将基于栈的方法调用转换成消息，将其发送给远程对象。为了让消息发送给远程对象，代理对象要使用到sink chain(可以看成是数据处理链)。首先，代理对象会调用第一个链节，将数据传给它。第一个链节获取数据后，对数据做进行处理，然后再将数据传递给下一个链接，以此类推。 在处理链中，有一个链节是formatter sink(格式处理链节)，其功能是将消息数据转换为stream(流)。之所以要在在格式链节处理数据之后，再将数据传递给下一个链节进行处理，是因为在这个节点，消息已经不再和数据类型相关，此刻的数据表现形势只是二进制字节流(我们可以对它做任何处理，对吧)。最后一个链节是transports sink，它的功能是将数据发送到服务器并等待回应。当它收到回应后，它会将数据传递前一个链节，直到最开始的那个链节将数据传递给代理对象。

当数据发送到服务器端后，服务器端也有一个sink chain，它的节点与客户端上的节点一致，只是顺序相反。在服务器上，处理数据的第一个节点是transport sink，数据沿着sink chain传递到真正的远程数据处理对象。

客户端：代理对象 -->formatter sink -->transport sink
服务器端：transport sink --> formatter sink --> 远程目标对象

在这个处理链中，我们可以加入自定义的链节。加入自定义链节的目的很多，而我所需要的是保证数据在网络上传输的安全性。在上面我们已经意识到，当消息经过formatter sink处理后，就以字节流的形式体现，而对字节的加密处理，对程序员来说是再简单不过的事情。所以，我要做的，就是在客户端，将加密处理链节加到formatter sink之后，在服务器端，将解密处理链节加到formatter sink之前。

上面这些内容看起来很简单，但要把它作出来，还需要很多工作。你确实可以通过.net 框架轻松实现分布式应用程序的功能，但是如果你要自定义其中的部分功能，事情就不象想象的那么容易了(至少不是几个继承能够解决问题的)。

开始艰难之旅

要实现自定义链节，首先要实现以下几个接口：
imessagesink，iclientchannelsink，iserverchannelsink，iclientsinkprovider，iserversinkprovider
虽然我们处理的只是加密问题，但是在.net 框架中，找不到一个链节处理的基类，所以下面的路会比较艰难。

 imessagesink：
    属性：
        nextsink：获取处理链中的下一个链节
    方法：
        asyncprocessmessage：异步处理获取的消息
        syncprocessmessage：同步处理获取得消息

iclientchannelsink：
    属性：
        nextchannelsink：获取客户端处理链节中的下一个链节
    方法：
        asyncprocessrequest：在当前的处理链节中，请求异步数据处理
        asyncprocessresponse：在当前的处理链节中，请求异步回应
        getrequeststrean：返回字节流到即将被序列化的消息上
        processmessage：从当前的处理链节中，请求消息处理

iserverchannelsink：
    属性：
        nextchannelsink：获取服务器端处理链节中的下一个链节
    方法：
        asyncprocessresponse：异步处理回应消息
        getresponsestream：返回流到即将被序列化的消息上
        processmessage：从当前链节请求消息处理
       

在上面几个接口中，最重要的是imessagesink。这个接口的同步处理与异步处理都要实现。以下是伪代码：
public __gc class basesink : imessagesink
{
private:
    imessagesink* nextmessagesink;
public:
//执行异步处理
imessagectrl* imessagesink::asyncprocessmessage(imesage* msg, imessagesink* replaysink)
{
    //处理发送的消息，对消息的加密处理在这里进行
    //创建返回的messagesink, replysink1，由replaysink1来处理返回的消息，该线程不必等待消息的回应
    return this->nextmessagesink.asyncprocessmessage(msg, replysink1);
}
//执行同步处理
imessage* imessagesink::syncprocessmessage(imessage* msg)
{
    //处理发送的消息，对消息的加密处理在这里进行
    imessage* resmsg = this->nextmessagesink.syncprocessmessage(msg);//获取返回的消息，线程在这里等待回应
    //处理返回的消息，并返回处理后的消息，对消息的解密处理在这里进行
}
__property imessagesink* imessagesink::get_nextsink()
{
    return this->nextmessagesink;
}
}

 在这里，万里长征终于走出了坚实的第一步了，攻克了imessagesink，相信后面的那几个接口会很好搞定。

文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!