.NET平台下可复用的Tcp通信层实现

    2006年已经来临，回首刚走过的2005，心中感慨万千。在人生和生活的目标上，有了清晰明确的定位，终于知道了自己喜欢什么样的生活，喜欢什么样的生活方式；在技术上，成熟了不少，眼界也开阔的不少，从面向对象到组件、从.Net到J2EE、从微软到开源，颇有收获。特别值得一提的是，认识了Rod Johnson这个大牛人，也终于在自己的项目中正式使用Spring.net框架来开发了，这确实是一个优秀的框架。而在已经到来的2006年，我有一个主要目标就是B/S应用开发，来填补自己在企业级开发上的另一半空白。     
    以前就很想将自己在Tcp通信层的开发心得、经验共享出来，但一直没有实现，究其原因，还是自己太懒了。今天终于找到一个时机，写下这篇文章，也算是对2005年的另一种形式的回忆吧。

    绝大多数C/S（包括多层）结构的系统中，终端与服务器的通信都是通过Tcp进行的（使用Udp的也有一些，但是其相对于Tcp简单许多，所以不在这里的讨论之列）。通常，这样的C/S系统都需要处理极大的并发，也就是说随时都可能有成千上万个用户在线，并且每分钟都可能有数以百计的用户上线/下线。由于每个用户都与服务器存在着一个Tcp连接，如何管理所有这些连接，并使我们的Tcp通信层稳定高效地工作，是我开发的这个“TcpTcp通信层”设计实现的主要目标。
    自从2004年9月开始至今，我就一直负责某C/S系统的服务器端的架构设计，并负责整个通信层的实现，在探索的过程中，逐渐形成了一套可复用的“Tcp通信层框架”（“框架”这个词真的蛮吓人，呵呵），其位于EnterpriseServerBase类库的EnterpriseServerBase.Network命名空间中。现将我在通信层这一块的设计/开发经验记录于此，以便日后回顾。也期大家多多赐教。
    我期望的“Tcp通信层”并不只是能接受连接、管理连接、转发用户请求这么简单，为了构建一个高度可复用的、灵活的、可接插的Tcp通信层，需要定义很多的规则、接口、契约，这需要做很多的工作。“Tcp通信层”决不仅仅只是Tcp协议通信，由于通信与消息联系紧密，不可避免的需要将“通信的消息”纳入到我们的分析中来，比如，基于Tcp传输的特性，我们可能需要对接收到的消息进行分裂、重组等（后文中会解释为什么、以及如何做）。请允许我在这里澄清一下，如果只是解决“仅仅”的Tcp通信问题，我只需要介绍Tcp组件就可以了，但是如果要解决“整个Tcp通信层”的问题，并使之可高度复用，那就需要介绍很多额外的东西，比如，上面提到的“消息”，以及“消息”所涉及的通信协议。
    在我们应用的通信层中，存在以Tcp组件为核心的多个组件，这些组件相互协作，以构建/实现高度可复用的Tcp通信层。这些组件之间的关系简单图示如下：
   
 

    我先解释一下上图。当网络（Tcp）组件从某个Tcp连接上接收到一个请求时，会将请求转发给消息分派器，消息分派器通过IDataStreamHelper组件获取请求消息的类型，然后根据此类型要求处理器工厂创建对应类型的请求处理器，请求处理器处理请求并返回结果。接下来再由网络组件把结果返回给终端用户。在消息分派器进行请求消息分派之前，可能涉及一系列的操作，像消息加密/解密、消息分裂/重组、消息验证等。而且，根据不同的应用，可能有其它的消息转换要求，而且这些操作可能是多样化的，为了满足这种多样性和可接插性，这就需要消息分派器提供一个插入点，让我们可以随心所欲地插入自定义的对请求/回复消息的预处理和后处理。
    上图中消息分派器中可接插的操作除了消息分裂器（使用实线框）是必须的，消息加密器和消息验证器（使用虚线框）是可选的，应根据你应用的实际情况加以决定是否使用。关于这几个典型的可接插的组件的功能作用会在后文中介绍。在继续介绍Tcp组件的实现之前，有必要先提一下IDataStreamHelper接口的作用，IDataStreamHelper接口用于抽象我们实际的通信协议，并能从任何一请求/回复消息中提取关于本条消息的元数据，比如，消息的长度、类型等信息。具体的应用必须根据自己的消息协议来实现IDataStreamHelper接口。关于该接口的定义也在后文中给出。
    关于上图，需要提醒的是，整个消息的流动是由Tcp组件驱动的！这篇文章以Tcp组件和消息分派器组件为索引来组织整个可复用的Tcp通信层的实现。首先，我们来深入到Tcp组件的具体实现中去。 

一．Tcp组件

1．Tcp组件的主要职责
       Tcp组件的主要职责并不是在一个很短的时间内总结出来的，它是逐步完善的（至今可能还不够全面）。为了使Tcp组件具有高度的可复用性，需要考虑很多的需求，而所有这些需求中具有共性的、占主导位置的需求就被纳入到Tcp组件的职责中来了。这个职责的集合如下：
（1）       管理所有的Tcp连接以及连接对应的上下文（Context）。
（2）       当某用户上线或下线时，能发出事件通知。
（3）       当在线用户（连接）的数量发生变化时，能发出事件通知。
（4）       当用户的请求得到回复时，发出事件通知。这一点对于记录用户请求和跟踪用户请求非常有用）
（5）       能及时主动关闭指定连接。比如，当某一非法用户登录后，用户验证组件通知Tcp组件强行关闭该用户对应的连接。
（6）       除了能转发用户请求及对请求的应答（通过消息分派器）外，还能直接对指定的用户发送数据。这也要求我们的Tcp连接是多线程安全的。
（7）       提供绕开Tcp组件直接从Tcp连接同步接收数据的功能。比如，客户端需要上传一个Blob，我们可能希望直接从Tcp连接进行接收数据，这是有好处的，后面可以看到。
    这里列出的是Tcp组件的主要职责，还有很多细节性的没有罗列出来，如果一个Tcp组件解决了上述所有问题，对我来说，应该就是一个很好用、很适用的Tcp组件了。

2．Tcp组件接口定义
       相信很多朋友和我一样，刚接触Tcp服务端开发的时候，通常是当一个Tcp连接建立的时候，就分配一个线程在该连接上监听请求消息，这种方式的缺点有很多，最主要的缺点是效率低、管理复杂。
    我的最初的Tcp组件是C++版本的，那时很有幸接触到了windows平台上最高效的Tcp通信模型――完成端口模型，完全理解这个模型需要点时间，但是《Win32 多线程程序设计》（侯捷翻译）和《windows网络编程》这两本书可以给你不少帮助。异步机制是完成端口的基础，完成端口模型的本质思想是将"启动异步操作的线程"和"提供服务的线程"（即工作者线程）拆伙。理解这一点很重要。在.Net中没有对应的组件或类对应于完成端口模型，解决方案有两个：一是通过P/Invoke来实现自己的完成端口组件，另一种方式是通过.Net的现有通信设施来模拟完成端口实现。
    本文给出第二种方案的实现说明，另外，我也给出通过“异步＋线程池”的方式的Tcp组件实现，这种方式对于大并发量也可以很好的管理。也就是我，我的EnterpriseServerBase类库中，有两种不同方式的Tcp组件实现，一个是模拟完成端口模型，一个是“异步＋线程池”方式。无论是哪种方式，它们都实现了相同的接口ITcp。ITcp这个接口涵盖了上述的Tcp组件的所有职责，这个接口并不复杂，如果理解了，使用起来也非常简单。我们来看看这个接口的定义：

    public interface ITcp :INet ,ITcpEventList ,ITcpClientsController
    {
        int ConnectionCount{get ;} //当前连接的数量
    }    

    这个接口继承了另外三个接口，INet ,ITcpEventList ,ITcpClientsController。INet接口是为了统一基于Tcp和Udp的通信组件而抽象出来的，它包含了以下内容：

    public interface INet
    {
        void InitializeAll(IReqestStreamDispatcher i_dispatcher ,int port , bool userValidated) ;        
        void InitializeAll() ;
        void UnitializeAll() ;        

        NetAddinType GetProtocalType() ; //Udp, Tcp
        event CallBackDynamicMessage DynamicMsgArrived ; //通常是通信插件中一些与服务和用户无关的动态信息，如监听线程重启等
        void Start() ;
        void Stop() ;

        IReqestStreamDispatcher Dispatcher{set;} //支持依赖注入
        int                        Port{get ;set ;}
        bool                    UserValidated{set ;}
    }
    
    public enum NetAddinType
    {
        Tcp ,Udp
    }    

    public delegate void CallBackDynamicMessage(string msg) ;

 

    IReqestStreamDispatcher就是我们上述图中的消息分派器，这是Tcp通信层中的中央，它的重要性已从前面的关系图中可见一斑了。IReqestStreamDispatcher需要在初始化的时候提供，或者通过Dispatcher属性通过IOC容器进行设值法注入。UserValidated属性用于决定当用户的第一个请求不是登录请求时，是否立即关闭Tcp连接。其它的属性已经加上了注释，非常容易理解。
    ITcpEventList接口说明了Tcp组件应当发布的事件，主要对应于前述Tcp组件职责的（2）（3）（4）点。其定义如下：

    public interface ITcpEventList
    {            
        event CallBackForTcpUser2   SomeOneConnected ;    //上线
        event CallBackForTcpUser1   SomeOneDisConnected ; //掉线
        event CallBackForTcpCount   ConnectionCountChanged ;//在线人数变化
        event CallBackForTcpMonitor ServiceCommitted ;//用户请求的服务的回复信息    
        event CallBackForTcpUser    UserAction ;        
    }

    每一个在线用户都对应着一个Tcp连接，我们使用tcp连接的Hashcode作为ConnectID来标志每一个连接。UserAction将用户与服务器的交互分为三类：登录、退出和标准功能访问，如以下枚举所示。

    public enum TcpUserAction
    {
        Logon , Exit , FunctionAccess , //标准的功能访问        
    }

最后一个接口ITcpClientsController，主要用来完成上述Tcp组件职责的（5）（6）（7）三点。定义如下：

    /// <summary>
    /// ITcpController 用于服务器主动控制TCP客户的连接
    /// </summary>
    public interface ITcpClientsController
    {
        //同步接收消息
        bool SynRecieveFrom(int ConnectID ,byte[] buffer, int offset, int size ,out int readCount) ;

        //主动给某个客户同步发信息
        void SendData(int ConnectID ,byte[] data) ;
        void SendData(int ConnectID, byte[] data ,int offset ,int size) ;

        //主动关闭连接
        void DisposeOneConnection(int connectID ,DisconnectedCause cause) ;
    }

 

    这个接口中的方法的含义是一目了然的。
    上述的几个接口已经完整的覆盖了前述的Tcp组件的所有职责，在了解了这些接口定义的基础上，大家已经能够使用EnterpriseServerBase类库中的Tcp组件了。如果想复用的不仅仅是Tcp组件，而是整个Tcp通信层，你就需要关注后面的内容。不管怎样，为了文章的完整性，我在这里先给出前面提到的Tcp组件的两种实现。 

3．Tcp组件基本元素实现
       在实现Tcp组件之前，有一些基本元素需要先建立起来，比如安全的网络流、Tcp监听器、用户连接上下文、上下文管理者等。（1）安全的网络流SafeNetworkStream
    前面已经提到过，为了能在Tcp组件外部 对指定的连接发送数据，必须保证我们的Tcp连接是线程安全的，而System.Net.Sockets.NetworkStream是非线程安全的，我们必须自己对其进行封装，以保证这一点。System.Net.Sockets.NetworkStream的线程安全的封装就是EnterpriseServerBase.Network.SafeNetworkStream类，它继承了ISafeNetworkStream接口：

 

    /// <summary>
    /// ISafeNetworkStream 线程安全的网络流 。
    /// 注意：如果调用的异步的begin方法，就一定要调用对应的End方法，否则锁将得不到释放。
    /// 作者：朱伟 sky.zhuwei@163.com 
    /// </summary>
     public interface ISafeNetworkStream :ITcpSender ,ITcpReciever
    {        
        void Flush();
        void Close() ;        
    }    

    //用于在TCP连接上发送数据，支持同步和异步
    public interface ITcpSender
    {                                                      
        void Write(byte[] buffer ,int offset ,int size) ;
        IAsyncResult BeginWrite(byte[] buffer, int offset, int size, AsyncCallback callback, object state );
        void EndWrite(IAsyncResult asyncResult    );
    }

    //用于在TCP连接上接收数据，支持同步和异步
    public interface ITcpReciever
    {
        int Read (byte[] buffer ,int offset ,int size) ;
        IAsyncResult BeginRead(    byte[] buffer, int offset, int size, AsyncCallback callback, object state );
        int EndRead(IAsyncResult asyncResult );
    }   

    该接口几乎与System.Net.Sockets.NetworkStream提供的方法一样，只不过它们是线程安全的。这样，针对同一个SafeNetworkStream，我们就可以在不同的线程中同时在其上进行数据接收/发送（主要是发送）了。

（2）Tcp监听器EnterpriseServerBase.Network.XTcpListener
    不可否认，System.Net.Sockets.TcpListener只是提供了一些最低阶的工作，为了将监听线程、端口、监听事件整合起来，我引入了EnterpriseServerBase.Network.XTcpListener类，它可以启动和停止，并且当有Tcp连接建立的时候，会触发事件。XTcpListener实现了IXTcpListener接口，其定义如下：

    public interface IXTcpListener
    {
        void Start() ; //开始或启动监听线程
        void Stop() ;  //暂停，但不退出监听线程

        void ExitListenThread() ;//退出监听线程

        event CBackUserLogon     TcpConnectionEstablished ; //新的Tcp连接成功建立
        event CallBackDynamicMsg DynamicMsgArrived ;
    }

    XTcpListener可以在不同的Tcp组件中复用，这是一种更细粒度的复用。
 

（3）用户连接上下文ContextKey
       ContextKey用于将所有的与一个用户Tcp连接相关的信息（比如接收缓冲区、连接的状态――空闲还是忙碌、等）封装起来，并且还能保存该用户的请求中上次未处理完的数据，将其放于接收缓冲区的头部，并与后面接收到的数据进行重组。说到这里，你可能不太明白，我需要解释一下。Tcp协议可以保证我们发出的消息完整的、有序的、正确的到达目的地，但是它不能保证，我们一次发送的数据对方也能一次接收完全。比如，我们发送了一个100Bytes的数据，对方可能要接收两次才能完全，先收到60Bytes，再收到40Bytes，这表明我们可能会收到“半条”消息。还有一种情况，你连续发了两条100Bytes的消息，而对方可能一次就接收了160Bytes，所以需要对消息进行分裂，从中分裂出完整的消息然后进行处理。这，就是前面所说的需要对消息进行分裂、重组的原因。知道这点后，IContextKey接口应该比较容易理解了，因为该接口的很多元素的存在都是为了辅助解决这个问题。IContextKey的定义如下：

 

    public interface IContextKey
    {
        NetStreamState       StreamState{get ;set ;}  //网络流的当前状态－－空闲、忙碌
        ISafeNetworkStream NetStream{get ;set ;}   

        byte[]  Buffer{get ;set ;}    //接收缓冲区
        int        BytesRead{get ;set ;} //本次接收的字节数
        int        PreLeftDataLen{get ;set ;}        
        bool    IsFirstMsg{get ;set ;} //是否为建立连接后的第一条消息

        int StartOffsetForRecieve{get ;} 
        int MaxRecieveCapacity{get ;} //本次可以接收的最大字节数
        RequestData RequestData{get ;}

        void ResetBuffer(byte[] leftData) ;//leftData 表示上次没有处理完的数据，需要与后面来的数据进行重组，然后再次处理
    }

    对于消息的分裂和重组是由消息分裂器完成的，由于Tcp组件的实现不需要使用消息分裂器，所以消息分裂器的说明将在后面的消息分派器实现中讲解。 

（4）上下文管理者ContextKeyManager
       ContextKeyManager用于管理所有的ContextKey，其实现的接口IContextKeyManager很容易理解：

 

    public interface IContextKeyManager
    {
        void InsertContextKey(ContextKey context_key) ;
        void DisposeAllContextKey() ;
        bool IsAllStreamSafeToStop() ; //是否可以安全退出
        void RemoveContextKey(int streamHashCode) ;
        int ConnectionCount {get ;}
        ISafeNetworkStream GetNetStream(int streamHashCode) ;
        event CallBackCountChanged StreamCountChanged ;
    }

    在上述四个基本元素的支持下，再来实现Tcp组件就方便了许多，无论是以何种方式（如完成端口模型、异步方式）实现Tcp组件，这些基本元素都是可以通用的，所以如果你要实现自己的Tcp组件，也可以考虑复用上述的一些基本元素。复用可以在不同的粒度进行，复用真是无处不在，呵呵。 

4．完成端口Tcp组件实现
    前面已经提到，完成端口模型本质思想是将"启动异步操作的线程"和"提供服务的线程"（即工作者线程）拆伙。只要做到这一点，就模拟了完成端口。
    分析一下我们需要几种类型的线程，首先我们需要一个线程来接收TCP连接请求，这就是所谓监听线程，当成功的接收到一个连接后，就向连接发送一个异步接收数据的请求，由于是异步操作，所以会立即返回，然后再去接收新的连接请求，如此监听线程就循环运作起来了（已经封装成前述的XTcpListener组件了）。值得提出的是，在异步接收的回调函数中，应该对接收到的数据进行处理，完成端口模型所做的就是将接收到的数据放在了完成端口队列中，注意，是一个队列。第二种线程类型，就是工作者线程。工作者线程的个数有个经验值是（ Cpu个数×2 ＋ 2），当然具体取多少，还要取决于你的应用的要求。工作者线程的任务就是不断地从完成端口队列中取出数据，并处理它，然后如果有回复，再将回复写入对应的连接。
    好，让我们来定义接口IRequestQueueManager，用于模拟完成端口的队列，该队列是线程安全的，用于将所有的请求进行排队，然后由工作者线程来轮流处理这些请求。

    public interface IRequestQueueManager :IRequestPusher
    {        
        object Pop() ;//弹出队列中的下一个请求
        void Clear() ;
        int Length {get ;} //队列长度
    }
    
    public interface IRequestPusher
    {
        void Push(object package) ; //向队列中压入一个请求
    }

    在IRequestQueueManager的基础上，可以将工作者线程和启动异步操作的线程拆开了。由于工作者线程只与端口队列相关，所以我决定将它们一起封装起来－－成为IIOCPManager，用于管理请求队列和工作者线程。

    /// <summary>
    /// IIOCPManager 完成端口管理者，主要管理工作者线程和完成端口队列。
    /// </summary>
    public interface IIOCPManager : IRequestPusher
    {
        void Initialize(IOCPPackageHandler i_packageHandler ,int threadCount) ;
        void Start() ; //启动工作者线程
        void Stop() ;  //退出工作者线程    

        int WorkThreadCount{get ;}

        event CallBackPackageHandled PackageHandled ;
    }

    //IOCPPackageHandler 用于处理从完成端口队列中取出的package
    public interface IOCPPackageHandler
    {
         void HandlerPackage(object package) ; //一般以同步实现
    }

    有了IRequestQueueManager和IIOCPManager的支持，实现基于完成端口模型的Tcp组件就非常简单了。当然，你也可以单独使用IIOCPManager。你只要提供一个监听者线程接收连接，并将从连接接收到的数据通过IRequestPusher接口放入端口队列就可以了。 当然，为了处理接收到的数据，我们需要提供一个实现了IOCPPackageHandler接口的对象给IOCPManager。值得提出的是，你可以在数据处理并发送了回复数据后，再次投递一个异步接收请求，以保证能源源不断的从对应的TCP连接接收数据。下面，我们来看基于完成端口模型的Tcp组件的完整实现。

完成端口Tcp组件



5．异步Tcp组件实现
    这种方式的主要思想是：当一个新的Tcp连接建立时，就在该连接上发送一个异步接收的请求（BeginRead），并在异步回调中处理该请求，当请求处理完毕，再次发送异步接收请求，如此循环下去。异步接收启用的是系统默认线程池中的线程，所以，在异步Tcp组件中不用显式管理工作线程。异步Tcp组件的实现相对于完成端口模型而言简单许多，也单纯一些，不用管理请求队列，不需使用工作者线程等等。但是，相比于完成端口模型，其也有明显的缺陷：一个Tcp连接绑定到了一个线程，即使这个线程是后台线程池中的。如果用户数量巨大，这对性能是极其不利的；而完成端口模型，则可以限定工作者线程的个数，并且可以根据应用的类型进行灵活调节。
    异步Tcp组件实现源码。 

 

 

异步Tcp组件


       今天介绍了Tcp通信层中的核心――Tcp组件，仅仅复用Tcp组件已经能为我们省去很多麻烦了，如果想进行更高层次的复用――整个Tcp通信层的复用，请关注本篇的续文。





 

posted @ 2006-01-04 15:40  zhuweisky  阅读(9445)  评论(15)  编辑  收藏  举报